cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

yurtesen
Miniboss

Segmentation fault with connection through ssh X forwarding

Hi,

I have CodeXL installed on an Ubuntu box with Kaveri processor. I realized that remote connections work from some machines and it does not work from some. I have one machine with AMD GPU that CodeXL works. But 2 machines with Nvidia GPUs which cause crash.

In the machine with Kaveri processor, the COMPUTE=:0 set when logging in which allows running OpenCL programs remotely.  But this seem to cause segmentation faults at CodeXL if the client machine is using a non-amd gpu (at least so far that seems to be the pattern). If I unset COMPUTE then CodeXL executes fine but does not seem to detect the GPU in the kaveri machine.

Is this a known bug? or is there a workaround for this?

Thanks,

0 Likes
1 Solution

Hi yurtesen,

SSH forwarding presents several problems to OpenCL/OpenGL work, as you have witnessed with the failing clinfo.

The recommended way to work with CodeXL on a remote platform is to run the CodeXL graphic client at hand and run the CodeXL Remote Agent on the remote target platform. Note: Communication between the client and agent is not secure and requires configuring your firewall to allow use of a few port numbers. The CodeXL Options dialog can be used to select these port numbers.



View solution in original post

0 Likes
8 Replies

Hi yurtesen,

1. The CodeXL client uses the OpenCL library for the system information, as well as to enable OpenCL debugging (as of v1.3). There is also the issue of OpenCL-OpenGL interop which might be breaking here. The latter part will change in the upcoming CodeXL version (so you will be able to run normally if OpenCL is not present. That being said, running the CodeXL client through SSH / X forwarding is not a tested scenario and may cause unexpected behavior - especially if the SSH client and server machines have different hardware configurations. The CodeXL client assumes it runs on the same machine that displays it.

2. That being said, CodeXL does have an option for remote debugging (added in v1.3) - so you can have the remote machine be debugged from the other machine (do note that debugging Windows machines from Linux and vice-versa does not yet work).

3. If you could provide us with the log files for the crash, we might be able to supply a better workaround / fix for the issue.

These files are generated in /tmp/ and are called CodeXL*-<username>.log.

Hope this helps,

1- I guess there could be some problem related to OpenGL but since CodeXL is actually running in the remote machine, shouldnt it be able to find the correct OpenCL libraries/devices?  It looks like the problem is having the COMPUTE variable showing the remote machine, but DISPLAY variable showing the ssh forwarding.

2- I will try this. Is there any security implemented for this? For example requiring a local user credentials?

3- I am not near a workstation with an nvidia gpu right now. But I will try to replicate the issue ASAP and update this thread.

0 Likes

Hello,

There is no log file in /tmp . All I see is the following right when launching CodeXL.

/opt/CodeXL/1.3.3487/bin/CodeXL
/opt/CodeXL/1.3.3487/bin/CodeXL: line 41: 22749 Segmentation fault      (core dumped) /opt/CodeXL/1.3.3487/bin/CodeXL-bin

Thanks,

Evren

0 Likes

I realized even things like 'clinfo' doesn't work properly when DISPLAY is set through ssh forwarding...

0 Likes
yurtesen
Miniboss

I am still having problems with CodeXL 1.6. I wonder if this issue will ever be fixed. It prints a slightly different message now, an assertion failure...

0 Likes

Hi yurtesen,

SSH forwarding presents several problems to OpenCL/OpenGL work, as you have witnessed with the failing clinfo.

The recommended way to work with CodeXL on a remote platform is to run the CodeXL graphic client at hand and run the CodeXL Remote Agent on the remote target platform. Note: Communication between the client and agent is not secure and requires configuring your firewall to allow use of a few port numbers. The CodeXL Options dialog can be used to select these port numbers.



0 Likes

Dorono, can you tell why the local machine needs to have an AMD GPU to run CodeXL from a remote machine which already has an AMD GPU? This does not make much sense on my mind. It is not like I am debugging a local program. I want to debug the program which is on the remote machine.

I tried the remote agent before but it was not working so good (I don't really remember exactly why this was at this point, it was a while ago when we used it last time). I wonder why AMD can not make it so that the remote agent is used automatically when X forwarding is used?

In addition, CodeXL does not even start from remote location when X forwarding is used. I need to copy it to local machine first, keep versions synced etc. This situation is quite inconvenient.  Also, nvidia's debuggers work fine over forwarded X connections. This is a real inconvenience which should be fixed. People will simply use tools which work out of the box from other  manufacturers, such as CUDA tools etc.

I suspect 1 reason might be that nvvp and Intel VTune profilers are written in java which have no requirements on their target machines when forwarding happens via SSH/X11-forwarding. But still a fix would be great!

0 Likes