gnunet-gtk crashed with SIGSEGV

[Milan Bouchet-Valat]

Binary package hint: gnunet-gtk

Using Gutsy. Starting gnunet-gtk without any modification. It always occurs, even after a complete --purge --reinstall.

ProblemType: Crash
Architecture: i386
Date: Tue Oct 30 15:29:47 2007
Disassembly: 0x1:
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/gnunet-gtk
NonfreeKernelModules: cdrom
Package: gnunet-gtk 0.7.1c-2ubuntu2
PackageArchitecture: i386
ProcCmdline: gnunet-gtk
ProcCwd: /home/milan
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=fr_FR.UTF-8
Signal: 11
SourcePackage: gnunet-gtk
StacktraceTop:
 ?? ()
 ?? () from /usr/lib/libgnunetnamespace.so.0
 ?? () from /usr/lib/GNUnet/libgnunetgtkmodule_fs.so
 ?? ()
 ?? ()
Title: gnunet-gtk crashed with SIGSEGV
Uname: Linux milan 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin plugdev scanner video

[Apport retracing service (apport)]

StacktraceTop:?? ()
listNamespaceHelper (fn=0x837884f "HBU7HPHJPFK9TFSGN5V1OPM2S69D8K2Q13MFPI620QB4M49R0N13PUG4UU3PPU1JBVC4DDNK0RL23FSOG1BD2LIOUJ3425L50O3U5C0",
disk_directory_scan (ectx=0x8074c50, dirName=0x83787c0 "/home/milan/.gnunet//data/namespaces/", callback=0xb2f084d0 <listNamespaceHelper>, data=0xbf8c1e38)
NS_listNamespaces (ectx=0x8074c50, cfg=0x8073f00, iterator=0x1, closure=0xb2f2e220) at namespace_info.c:378
fs_namespace_start () at namespace.c:1434

[Luca Falavigna (dktrkranz)]

Thank you for your bug report.
gnunet-gtk starts succesfully on my box. Could you please attach output of ldd /usr/bin/gnunet-gtk command?

[Milan Bouchet-Valat (nalimilan)]

Are you using 0.7.2c for both gnunet-daemon and gnunet-gtk? I have noticed that in Gutsy, gnunet is 0.7.2c and gnunet-gtk is 0.7.1, which is quite bad! On my two machines, I get this segfault. Installing gnunet-gtk 0.7.2c from debian sid solved the issue. So I thought the version mismatch was the issue.

milan@milan:~$ ldd /usr/bin/gnunet-gtk
        linux-gate.so.1 => (0xffffe000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7c23000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7b9c000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7b80000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7b68000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7b5f000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7b34000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7b26000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7b1e000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7b1a000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb7b12000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7b0c000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7b03000)
        libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb7b00000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb7afd000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7abf000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb7a48000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb7957000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7952000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7917000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7913000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb790e000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7851000)
        libgnunetutil.so.1 => /usr/lib/libgnunetutil.so.1 (0xb7838000)
        libgnunetutil_boot.so.0 => /usr/lib/libgnunetutil_boot.so.0 (0xb7835000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7830000)
        libgnunetgtk_common.so.0 => /usr/lib/libgnunetgtk_common.so.0 (0xb782a000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7805000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb77ed000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb76a3000)
        libglade-2.0.so.0 => /usr/lib/libglade-2.0.so.0 (0xb768b000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb765d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb75ec000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb75d7000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb75b7000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb75b4000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7591000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb758b000)
        /lib/ld-linux.so.2 (0xb7fbd000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb753a000)
        libadns.so.1 => /usr/lib/libadns.so.1 (0xb7528000)
        libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb74e3000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb74b5000)
        libltdl.so.3 => /usr/lib/liblt...

[Luca Falavigna (dktrkranz)]

Yes, I used the same versions you mentioned and I received no crashes.

[Milan Bouchet-Valat (nalimilan)]

Anyway, it is working with 0.7.2 so I don't see the point in fixing this bug: even if we do this, it won't go into Gutsy more easily than accepting the current 0.7.2 package. Would it be worth/acceptable by the Technical Board?

[Luca Falavigna (dktrkranz)]

Probably a backport could be enough to fix this bug in Gutsy. If you're interested, you can proceed that way. For now, I think this bug can be closed.

[Milan Bouchet-Valat (nalimilan)]

0.7.2 solves this. Asking for a backport.

[Milan Bouchet-Valat (nalimilan)]

To the backports team: would you accept gnunet-gtk 0.7.2 when it gets into Hardy ?
http://packages.ubuntu.com/hardy/net/gnunet-gtk
Debian has this version for a while and it installs without any issue in Gutsy. I don't know why I did not enter into Gutsy & Hardy, but it should have followed gnunet, which is already 0.7.2 here.

I know this would be a bugfix release, but it will not be accepted for SRU it since it changes minor version, though this version mismatch should better be corrected. Thanks.

[John Dong (jdong)]

Am I correct in understanding that the gnunet-gtk client in Gutsy is mismatched with the gnunet server altogether, making gnunet-gtk in Gutsy completely nonfunctional?

IF so we can try the (1) Backport (2) Test (3) Copy to -updates path similar to what we are doing with Azureus. At any rate, I will triage this as a backport for now.

[John Dong (jdong)]

Marking Incomplete until the right version hits Hardy

[Milan Bouchet-Valat (nalimilan)]

This explanation corresponds to what I encounter on two different machines. Though, it seems that for some people the current Gutsy situation is working. But since to fix this bug we need an update anyway, I think you'r right, the best would be a (logical) backport.

For the test, I can confirm it works right here with gnunet-gtk 0.7.2 picked directly from Debian. So let's wait until it enters Hardy...

[Milan Bouchet-Valat (nalimilan)]

gnunet-gtk in Hardy is now 0.7.2c-3: backport is possible.

[Scott Kitterman (kitterman)]

If the package is "not working", then I think this should be done in -updates, not -backports.

[Milan Bouchet-Valat (nalimilan)]

I agree, but would this shift from 0.7.1 to 0.7.2 be accepted? This is a minor version change, but this version mismatch the result of a problem with sync with Debian (dependencies should be fixed for next version, I'll report that to them).

[John Dong (jdong)]

What would be the justification(s) for an upgrade to 0.7.2?

[John Dong (jdong)]

Incomplete pending answer to previous question.

[Milan Bouchet-Valat (nalimilan)]

Sorry for not answering, I did not understand what you needed.
The rationale for backporting 0.7.2 would be 1) to avoid this crash (known to be fixed by installing 0.7.2) and 2) match the gnunet package version with gnunet-gtk's (this may fix other bugs because the version mismatch is not really a good idea in this beta software). But now it's a bit late, maybe you have more important work to do: in a few weeks, gnunet 0.8 will be available and 0.7.2 will not be compatible with the new network protocol.

So please choose what you think is best, I won't complain if you close the report...

[John Dong (jdong)]

Thanks for your response and flexibility. After a bit of thought, I think this is the best way to treat it:

(1) If there are enough testers interested, consider trying a Stable Release Update to deal with this crash via gutsy-updates, as Backports really isn't for solving crashing bugs.

(2) When gnunet-gtk 0.8.0 becomes available (most likely via Hardy+1) then let's do a backport across Hardy and Gutsy.

(3) On the other hand, if you feel that gnunet-gtk in hardy is well tested already as a backport, let me know exactly what packages need backporting (this bug ticket is getting long enough to be hard to follow)

So, given that, I'm going to close this bug report for now. If you do not agree with this decision, I'm very flexible, so feel free to re-open :)

[Milan Bouchet-Valat (nalimilan)]

Just leave it closed. ;-)
It would be better to concentrate on the new 0.7.4 (replacing 0.8.0) that will soon introduce a protocol breakage than working on a fix for two months. 0.7.2 will not have any value when 0.7.4 is out.

If 0.7.4 does not enter Hardy, I'll open a new bug report to backport it very soon - and that will be much more important IMHO. Thanks for your work anyway.

[Milan Bouchet-Valat (nalimilan)]

Fixed in Hardy.