After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731336 - Segmentation fault when connecting to SSH with no user
Segmentation fault when connecting to SSH with no user
Status: RESOLVED OBSOLETE
Product: gnome-commander
Classification: Other
Component: application
1.4.x
Other Linux
: Normal normal
: 1.4
Assigned To: GNOME Commander maintainer(s)
GNOME Commander maintainer(s)
Depends on: 589069
Blocks:
 
 
Reported: 2014-06-06 15:01 UTC by Helge Willum Larsen
Modified: 2015-05-19 19:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GDB backtrace log (3.06 KB, text/x-log)
2014-06-06 15:01 UTC, Helge Willum Larsen
Details
GDB backtrace from core dump (2.28 KB, text/x-log)
2014-06-19 09:31 UTC, Helge Willum Larsen
Details

Description Helge Willum Larsen 2014-06-06 15:01:52 UTC
Created attachment 278038 [details]
GDB backtrace log

gnome-commander: 1.4.2-1
Running on an up-to-date Arch Linux installation.

Steps to repoduce:
==================
1) Connections -> Remote Server... (CTRL+F)
2) Add
  Service type: SSH
  Alias: example.org
  Server: example.org
  (leave all other fields empty, including User name)
3) OK, Connect
4) program crashed with Segmentation fault (core dumped)

Workaround:
===========
If I specify the same username as in my ~/.ssh/config, it works as expected.
Comment 1 André Klapper 2014-06-06 23:47:34 UTC
Backtrace has not a single call from gnome-commander:

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6400c10 in gdk_window_set_geometry_hints () from /usr/lib/libgdk-x11-2.0.so.0
Comment 2 Helge Willum Larsen 2014-06-08 22:29:38 UTC
Oh, alright, so the backtrace is not much help then, I guess...
I must admit, I am fairly inexperienced in debugging.

I have no problems reproducing the bug - it is very consistent.
Could you give me any pointers on how to properly debug and provide relevant details?

Cheers.
Comment 3 Uwe Scholz 2014-06-15 15:56:02 UTC
Just try it with these commands:

"ulimit -c unlimited"
"gnome-commander"

Now reproduce the bug -> a core file should be created

"gdb gnome-commander core"
"bt"

This should give a backtrace of the last functions executed in gcmd.

Paste the output here.

"quit"

You can remove the core file now.
Comment 4 Uwe Scholz 2014-06-16 21:24:11 UTC
After some testing I could recreate this behavior. Seems to be a bug related to the gnome-vfs interface.
Comment 5 Helge Willum Larsen 2014-06-19 09:31:46 UTC
Created attachment 278749 [details]
GDB backtrace from core dump

Thanks for helping, Uwe Scholz.

On the first try, after setting ulimit -c, gnome-commander managed to get an authorization dialog to appear, but then, when I cancelled it, it just hang at 100% CPU until I killed it.
Perhaps we have a race condition somewhere.

I got the usual segfault on my second try and was able to retrieve the core file via systemd-coredumpctl. This backtrace is attached.
Comment 6 Uwe Scholz 2014-06-20 09:11:26 UTC
Thank you. Again, the bt has no relation to GCMD. Its hard to guess what causes the error in that case. But as said before, the problem might be related to gnome-vfs, as it is responsible for remote connections in GCMD. A workaround could be not to allow the user to leave the fields in the connections dialog empty. Will think about that...
Comment 7 Uwe Scholz 2015-05-19 19:49:16 UTC
Hi,

after closing bug #653573 I again tried to reproduce crash of Gnome Commander with the given example input given in post #1. But I could not reproduce the crash anymore. I'm not 100% sure, but I think this bug is now obsolete. Don't hesitate to reopen the bug if you could reproduce the crash with Gnome Commander v1.4.6 or later.