Debugging L-Series with Eclipse

Discussion:

(too old to reply)

John Wilson

2023-09-14 21:12:03 UTC

Hi All -

With the migration to the L-Series (X86), the manuals indicate that debugging using Visual Inspect will no longer be possible.

When attempting to debug using Eclipse (using instructions from NSDEE manual) there seems to be an issue with how Eclipse invokes the debug session and which CPU is used.

Has anyone experienced this? Or are you using Eclipse debugging without any issue?

Thanks,
John

Randall

2023-09-15 21:08:28 UTC

Permalink

Post by John Wilson
Hi All -
With the migration to the L-Series (X86), the manuals indicate that debugging using Visual Inspect will no longer be possible.
When attempting to debug using Eclipse (using instructions from NSDEE manual) there seems to be an issue with how Eclipse invokes the debug session and which CPU is used.
Has anyone experienced this? Or are you using Eclipse debugging without any issue?
Thanks,
John

Hi John,

No issues for me on using NSDEE, ECLIPSE, and GDB, but you do need to have your SSH connections set up prior to attempting to debug. You should be using the latest version of NSDEE (or appropriate version for your system). There also could be a firewall issue, and also a port forwarding setup requirement in SSH2. The important "trick" is that you will be entering GDB commands via a console window in ECLIPSE, which is not normally input enabled, but the remote debugging does set up input to enter commands. The debug at line function had some issues (clicking on the line in the code window), but I thought that was resolved long ago. Please contact GNSC for support rather than here as this is a HPE supported product.

Regards,
Randall

wilso...@gmail.com

2023-09-18 12:30:10 UTC

Permalink

Post by Randall

Hi John,
No issues for me on using NSDEE, ECLIPSE, and GDB, but you do need to have your SSH connections set up prior to attempting to debug. You should be using the latest version of NSDEE (or appropriate version for your system). There also could be a firewall issue, and also a port forwarding setup requirement in SSH2. The important "trick" is that you will be entering GDB commands via a console window in ECLIPSE, which is not normally input enabled, but the remote debugging does set up input to enter commands. The debug at line function had some issues (clicking on the line in the code window), but I thought that was resolved long ago. Please contact GNSC for support rather than here as this is a HPE supported product.
Regards,
Randall

Hi Randall,

I will double check into the port forwarding, and will follow up with GNSC. Thanks!

Bill Honaker

2023-09-18 17:37:10 UTC

Permalink

John, not sure what you mean by the issue. Can you decribe errors or issues more clearly? As Randall said, you need to setup the SSH session correctly.
In the 'Mian' tab of the 'NonStop Application' configuration, click the 'Edit...' button by the NonStop system choice.
There, you should see options to setup SSH (or the Telnet/FTP which is discouraged). Once you think it's correct, click 'Connect' to see if it connects.
Then you can Apply and Close, and click Debug on the configuraiton page.

That session stays open for the duration of your Eclipse session unless you specifically disconnect it.

Good luck,
Bill

John Wilson

2023-09-26 20:56:03 UTC

Permalink

John, not sure what you mean by the issue. Can you decribe errors or issues more clearly? As Randall said, you need to setup the SSH session correctly.
In the 'Mian' tab of the 'NonStop Application' configuration, click the 'Edit...' button by the NonStop system choice.
There, you should see options to setup SSH (or the Telnet/FTP which is discouraged). Once you think it's correct, click 'Connect' to see if it connects.
Then you can Apply and Close, and click Debug on the configuraiton page.
That session stays open for the duration of your Eclipse session unless you specifically disconnect it.
Good luck,
Bill

The error I am seeing inside of Eclipse is:
"The debugger process started on CPU 2 instead of CPU 0 as expected. The NonStop host may be configured to restrict user access to certain CPUs, or system-load balancing software may be installed that overrides user-assigned CPU values." Followed with "Error starting process"

Initially when we opened a ticket with HPE previously, they stated that there is a round robin setup with the CPUs and if we kept attempting the debugging multiple times it would eventually begin on the correct CPU.

I will take a look at the additional SSH setup parameters and see if that may be related.

Thanks!

Bill Honaker

2023-09-26 21:40:12 UTC

Permalink

Post by John Wilson

John, not sure what you mean by the issue. Can you decribe errors or issues more clearly? As Randall said, you need to setup the SSH session correctly.
In the 'Mian' tab of the 'NonStop Application' configuration, click the 'Edit...' button by the NonStop system choice.
There, you should see options to setup SSH (or the Telnet/FTP which is discouraged). Once you think it's correct, click 'Connect' to see if it connects.
Then you can Apply and Close, and click Debug on the configuraiton page.
That session stays open for the duration of your Eclipse session unless you specifically disconnect it.
Good luck,
Bill

"The debugger process started on CPU 2 instead of CPU 0 as expected. The NonStop host may be configured to restrict user access to certain CPUs, or system-load balancing software may be installed that overrides user-assigned CPU values." Followed with "Error starting process"
Initially when we opened a ticket with HPE previously, they stated that there is a round robin setup with the CPUs and if we kept attempting the debugging multiple times it would eventually begin on the correct CPU.
I will take a look at the additional SSH setup parameters and see if that may be related.
Thanks!

John,

If your userid is prohibited from running programs in certain CPUs, that is possibly a scenario that the NSDEE developer didn't allow for.

Have you tried, on the Dubg Configurations page, 'Argument's tab, using "-cpu 2" in the 'Run command options' field?
That may only apply tot he process you're planning to debug... not the debugger itself, but worth a try.

Good luck,
Bill