segfault

[nsajko]

When I tried to close the application, a segmentation fault happened.

Coredump: https://drive.google.com/folderview?id=0B63rdrZtwIE9fmxkT0xwVGRTeHd6QW1HSGtvU2tQR3NYNGhDX2J2TU96aVhkdzg3OG9sZUU&usp=sharing

BTW, it couldn't display any imagefiles or videos while running.

[eduarrrd]

Coredumps are dependent on the specifics of binary you use (and exact versions of libraries, etc, bla, bla). http://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces does a great explanation of how to get good backtraces. (Obviously you should skip the Gentoo stuff if you're not on Gentoo.) The last listing should be particularly useful.

On Sun Feb 15 2015 at 4:25:34 PM Neven Sajko notifications@github.com wrote:

When I tried to close the application, a segmentation fault happened.

Coredump:

https://drive.google.com/folderview?id=0B63rdrZtwIE9fmxkT0xwVGRTeHd6QW1HSGtvU2tQR3NYNGhDX2J2TU96aVhkdzg3OG9sZUU&usp=sharing

BTW, it couldn't display any imagefiles or videos while running.

— Reply to this email directly or view it on GitHub https://github.com/tomvanbraeckel/3dfsb/issues/10.

[nsajko]

OK, I loaded the core dump in gdb and here are backtraces from 3 threads: (gdb) t a a backtrace Thread 3 (Thread 0x7f174d72c8c0 (LWP 8412)):

0 0x00007f173da4f800 in ?? () from /usr/lib/liborc-0.4.so.0

1 0x00007f174d54f815 in _dl_fini () from /lib64/ld-linux-x86-64.so.2

2 0x00007f17494acdb2 in __run_exit_handlers () from /usr/lib/libc.so.6

3 0x00007f17494ace05 in exit () from /usr/lib/libc.so.6

4 0x000000000040432d in ende (code=0) at 3dfsb.c:471

5 0x000000000041007a in keyboard (key=27 '\033') at 3dfsb.c:3505

6 0x00000000004110d5 in main (argc=1, argv=0x7ffffd11ceb8) at 3dfsb.c:3891

Thread 2 (Thread 0x7f1736ca9700 (LWP 8444)):

0 0x00007f174955af89 in syscall () from /usr/lib/libc.so.6

1 0x00007f174cd5e297 in g_cond_wait_until () from /usr/lib/libglib-2.0.so.0

2 0x00007f174cceea69 in ?? () from /usr/lib/libglib-2.0.so.0

3 0x00007f174cd40f60 in ?? () from /usr/lib/libglib-2.0.so.0

4 0x00007f174cd405f5 in ?? () from /usr/lib/libglib-2.0.so.0

5 0x00007f174c604374 in start_thread () from /usr/lib/libpthread.so.0

6 0x00007f174955f27d in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7f1736290700 (LWP 8451)):

0 0x0000000000404762 in getpixel (surface=0x7f1738022e30, x=30245, y=0) at 3dfsb.c:599

1 0x00000000004048f5 in ScaleSurface (Surface=0x7f1738022e30, Width=8192, Height=8192) at 3dfsb.c:637

2 0x0000000000404eb4 in get_image_from_file (filename=0x7f173628ed70 "/home/nsajko/feh_002582_000001_IMG_20141215_170037.jpg", filetype=1) at 3dfsb.c:791

3 0x0000000000405109 in async_load_textures (arg=0x0) at 3dfsb.c:860

4 0x00007f174c604374 in start_thread () from /usr/lib/libpthread.so.0

5 0x00007f174955f27d in clone () from /usr/lib/libc.so.6

[tomvanbraeckel]

Interesting. Looks like you exited while the texture making thread was still running, doing the getpixel() operation on a surface that comes from GStreamer. That x=30245 shouldn't be... let me dig into the code... thanks a lot for the report!

[tomvanbraeckel]

Hmm, was this with the latest version from GIT of release 1.2 or older? In my 3dfsb.c at line 599, there is no getpixel() function... This logic has been moved to media.c before the 1.2 came out... Can you try again with at least the 1.2 release? Thanks!

[tomvanbraeckel]

When exiting, GStreamer is cleaned up but the texture rendering thread was not explictly stopped (the OS cleans it up). Fixed now in commit 6e948f2ab9d32dde6ed854c3e5040d4afb5e169c. Thanks for reporting!

[nsajko]

No problem, I'm glad I could help. I was using version 1.1 btw