GNOME Bugzilla – Bug 573882
ekiga crashes on startup
Last modified: 2009-03-24 12:06:10 UTC
This is on Mandriva Cooker with ekiga 3.1.2: GNU gdb 6.8-5mdv2009.1 (Mandriva Linux release 2009.1) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-mandriva-linux-gnu"... (gdb) run Starting program: /usr/bin/ekiga [Thread debugging using libthread_db enabled] Detaching after fork from child process 31865. [New Thread 0xb5324990 (LWP 31862)] Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) thread apply all bt full
+ Trace 213099
Thread 1 (Thread 0xb5324990 (LWP 31862))
This is with libavcodec from subversion r17730.
Which versions of OPAL/PTLIB?
This is with ekiga 3.1.2, so it uses ptlib 2.6.0 and opal 3.6.0 as required.
Can you try to find out the cause? To put it simply, Craig is the only one to be able to fix that. However, he does not answer to e-mails anymore. So if nobody fixes it, either we release it broken, or we don't release.
How, can you give me a hint on debugging this?
I'll upgrade to libavcodec52 3:20090222-0.0 and see how it works here.
Note: some codecs do not yet compile with newest ffmpeg: http://www.nabble.com/Can't-compile-opal-with-avcodec-td21097280.html
It works with the above version. (20090222). Götz are you sure you run it with the same version of ffmpeg than you compiled it with?
Yes, I'm absolutely sure.
Then you will have to use gdb to see where it crashes. It will give a hint to Robert and Craig for debugging this.
I have aleady posted the backtrace, what else do you want me to do?
Help determining where it comes from the best you can. None of us can reproduce your issue.
Could you please give me a step by step instruction? BTW Might this be related to the stackalign option for libavcodec? Should I try to enable that one?
Perhaps you could try the stackalign thing. It is very hard to give a step by step guide :-/
The stackalign option does not help. Same crash with ffmpeg 0.5 compiled like this: ./configure --enable-shared --enable-postproc --enable-gpl --enable-pthreads --enable-libtheora --enable-libvorbis --enable-x11grab --enable-swscale --enable-libmp3lame --enable-libfaad --enable-libfaac --enable-libx264
With ffmpeg 0.5 it crashes on i586 with or without stackalign hack. On x86_64, it crashes with the stackalign hack but it does work without it.
Here's the backtrace on x86_64 with the stack align hack enabled: [?1034hGNU gdb 6.8-5mdv2009.1 (Mandriva Linux release 2009.1) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-mandriva-linux-gnu"... [Thread debugging using libthread_db enabled] [New Thread 0x2ab1d960ff30 (LWP 18149)] Program received signal SIGSEGV, Segmentation fault. 0x00002ab1dc1aed7f in DynaLink::InternalOpen (this=0x2ab1dc3b3620, dir=0x2ab1dc1b1172 "", name=0x2ab1dc1b0a90 "libavcodec.so.52") at ../common/dyna.cxx:90 90 WITH_ALIGNED_STACK({ // must be called before using avcodec lib
+ Trace 213544
Thread 1 (Thread 0x2ab1d960ff30 (LWP 18149))
Still happens in ekiga 3.2.0 with ptlib 2.6.1 and opal 3.6.1.
I think I have found the problem, it was caused by Mandriva's default optimization flags: -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer -march=i586 -mtune=generic -fasynchronous-unwind-tables
Which one of them was the problem?
The combination -O2 -Wp,-D_FORTIFY_SOURCE=2 breaks the build. -O2 or -Wp,-D_FORTIFY_SOURCE=2 alone do no harm, only the combination. This is with Mandriva's gcc 4.3.2.
And is it supposed to be a bug on our side or in ffmpeg itself?
Fortify is supposed to detect buffer overflows. So I guess there's a buffer overflow in opal.
Not related to the crash but I had a look at that part of the code (DynaLink::InternalOpen) and I think the code is wrong: ===== char path[1024]; memset(path, 0, sizeof(path)); // Copy the directory to "path" and add a separator if necessary if (strlen(path) > 0) { ===== Last line should probably be: if (dir && strlen(dir) > 0) {
The last line you quote is correct, and your fix doesn't seem to be : - 'path' can't be null since it's declared as "char path[1024];" ; - your fix uses 'dir' when the line is about 'path'.
strlen(path) can never be > 0 because of the memset, so the test is always false and dir is currently always ignored. I use dir instead of path because I think that the test should be on dir and not on path (The code is there to add "dir/" before "name" when dir is not empty)
Indeed ; I should probably read the full code.
Closing, since this was reported upstream (https://sourceforge.net/tracker/?func=detail&aid=2689828&group_id=204472&atid=989748).
For info, comment #24 was fixed upstream: 2009-03-24 04:16 rjongbloed * plugins/video/common/dyna.cxx: Added fix for video plug in shared library loading, current code would not look anywhere but default path. Thanks various people at http://bugzilla.gnome.org/show_bug.cgi?id=573882#c24