[Motmot] Segmentation faults

Thu Mar 26 18:49:13 UTC 2009

Just for kicks, I thought I'd try this on my machine, too (I haven't
been doing long runs yet). Instead of segmentation faults, I get
"illegal instructions" after 1-30 minutes.

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0x42d5c950 (LWP 18392)]
0x0000000042d5ac38 in ?? ()
(gdb) bt
#0  0x0000000042d5ac38 in ?? ()
#1  0x00007fa17641ba01 in raw1394_loop_iterate () from /usr/lib/libraw1394.so.8
#2  0x00007fa17641c43e in raw1394_write () from /usr/lib/libraw1394.so.8
#3  0x00007fa1766395a0 in platform_camera_write ()
   from /usr/lib/libdc1394.so.22
#4  0x00007fa17662a696 in dc1394_video_set_transmission ()
   from /usr/lib/libdc1394.so.22
#5  0x00007fa17689282b in CCdc1394_close ()
   from /usr/lib/libcam_iface_dc1394.so
#6  0x00007fa176893609 in delete_CCdc1394 ()
   from /usr/lib/libcam_iface_dc1394.so
#7  0x00007fa1951afaec in ffi_call_unix64 ()
   from /usr/lib/python2.5/lib-dynload/_ctypes.so
#8  0x00007fa1951af975 in ffi_call ()
   from /usr/lib/python2.5/lib-dynload/_ctypes.so
#9  0x00007fa1951aa907 in _CallProc ()
   from /usr/lib/python2.5/lib-dynload/_ctypes.so
#10 0x00007fa1951a455f in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
#11 0x0000000000417e33 in PyObject_Call ()
#12 0x000000000048617a in PyEval_EvalFrameEx ()
#13 0x0000000000488c07 in PyEval_EvalFrameEx ()
#14 0x000000000048a406 in PyEval_EvalCodeEx ()
#15 0x00000000004d5223 in ?? ()

Also, remember I said I got segfaults at camera startup occasionally
(right after clicking "OK" to initialize camera)? Here's one:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fd2629286e0 (LWP 18074)]
0x00007fd261b94330 in memset () from /lib/libc.so.6
(gdb) bt
#0  0x00007fd261b94330 in memset () from /lib/libc.so.6
#1  0x00007fd253015073 in ?? () from /usr/lib/dri/fglrx_dri.so
#2  0x00007fd252fcf246 in ?? () from /usr/lib/dri/fglrx_dri.so
#3  0x00007fd2535d4e36 in ?? () from /usr/lib/dri/fglrx_dri.so
#4  0x00007fd2535ecab3 in ?? () from /usr/lib/dri/fglrx_dri.so
#5  0x00007fd2535ee8d7 in ?? () from /usr/lib/dri/fglrx_dri.so
#6  0x00007fd253a36662 in ?? () from /usr/lib/dri/fglrx_dri.so
#7  0x00007fd254ba35e6 in ?? () from /usr/lib/libGL.so.1
#8  0x00007fd254ba3a33 in glXCreateContext () from /usr/lib/libGL.so.1
#9  0x00007fd241b0fc5d in wxGLContext::wxGLContext ()
   from /usr/lib/libwx_gtk2u_gl-2.8.so.0
#10 0x00007fd241b0fce5 in ?? () from /usr/lib/libwx_gtk2u_gl-2.8.so.0
#11 0x00007fd25cf69bbf in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#12 0x00007fd25cf7d7e8 in ?? () from /usr/lib/libgobject-2.0.so.0
#13 0x00007fd25cf7f245 in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#14 0x00007fd25cf7f633 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#15 0x00007fd25dd13957 in gtk_widget_realize ()
   from /usr/lib/libgtk-x11-2.0.so.0
#16 0x00007fd25dd13bd8 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x00007fd25dc599d6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#18 0x00007fd25db78139 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#19 0x00007fd25cf69c8c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0

I wish I could help you debug this stuff, but I have no idea where to
start with your code. If it helps, you should still have access to
this machine.

JB

On Thu, Mar 26, 2009 at 2:10 PM, Andrew Straw <astraw at caltech.edu> wrote:
> Hi Jon,
>
> The segmentation fault issue is strange... We haven't had that here.
>
> But if you're up for a little command-line work, I think we can isolate
> it. Run fview from within gdb, the GNU debugger:
>
> Type "gdb python" in the terminal window. After a blurb, you'll get the
> "(gdb)" prompt. Type "run /usr/bin/fview". A bunch of text will get
> printed (stuff about no debugging symbols found, etc). You'll have to
> press enter a few types at the "Type <return> to continue" text. Then,
> fview should be running as normal.
>
> When it segfaults, however, it won't close the program but rather return
> control to gdb. At that point, type "bt" at the "(gdb)" prompt to get a
> backtrace. Send that back to this email list, especially the first
> several lines, and we'll go from there. It'll show which function is
> crashing.
>
> -Andrew
>
> John Schneider wrote:
>> Hey Andrew,
>>
>> We have run into another problem:
>> Three separate computers with fresh Hardy installs, fully updated and
>> the latest fview/ctrax give segmentation faults at random intervals.
>> Sometimes they go for an hour or longer, other times they segfault
>> within 20min. They do not seem to output errors in fview.log so I'm at
>> a loss as to how to report specifics of the error.
>> In terms of hardware the only common feature of all three is the e5200
>> processor they have. I have run Memtest86 on them overnight and no
>> errors have shown up yet so I don't think it's the RAM... Any
>> input/advice in solving or diagnosing is appreciated.
>>
>> Jon
>>
>> PS The view->set view interval worked great (letting us use onboard
>> graphics) and I checked and somehow the drive was NTFS, formatting it
>> to ext3 along with 'view interval' seems to be working great.
>> _______________________________________________
>> Motmot mailing list
>> Motmot at code.astraw.com
>> http://code.astraw.com/cgi-bin/mailman/listinfo/motmot
>>
>
>
> --
> Andrew D. Straw, Ph.D.
> California Institute of Technology
> http://www.its.caltech.edu/~astraw/
> _______________________________________________
> Motmot mailing list
> Motmot at code.astraw.com
> http://code.astraw.com/cgi-bin/mailman/listinfo/motmot
>