I also got a segmentation fault tonight from the firewire camera running fview and flytrax for <40 minutes. This is the first time this has ever happened to me in the middle of running experiments. <br>the last error in the log is:<br>
ERROR trying to close camera: src/cam_iface_dc1394.c (909): libdc1394 err -12: RAW1394 failure<br>but the time it was last modified is right when I was starting the program. <br>Alice<br><br><div class="gmail_quote">On Thu, Mar 26, 2009 at 4:23 PM, Andrew Straw <span dir="ltr"><<a href="mailto:astraw@caltech.edu">astraw@caltech.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">John Schneider wrote:<br>
> I get the same output from the backtrace for all three computers:<br>
> ...<br>
> (no debugging symbols found)<br>
> [New Thread 0xaf6b8b90 (LWP 9591)]<br>
> [New Thread 0xaeeb7b90 (LWP 9592)]<br>
> (no debugging symbols found)<br>
> [New Thread 0xae656b90 (LWP 9593)]<br>
> (no debugging symbols found)<br>
> [New Thread 0xade55b90 (LWP 9594)]<br>
><br>
> Program received signal SIGSEGV, Segmentation fault.<br>
> [Switching to Thread 0xae656b90 (LWP 9593)]<br>
> 0x00000000 in ?? ()<br>
> (gdb) bt<br>
> #0 0x00000000 in ?? ()<br>
> #1 0xaf78860c in raw1394_loop_iterate () from /usr/lib/libraw1394.so.8<br>
> #2 0xaf789348 in raw1394_write () from /usr/lib/libraw1394.so.8<br>
> #3 0xaf7a7ff7 in platform_camera_write () from /usr/lib/libdc1394.so.22<br>
> #4 0xaf79bdb9 in dc1394_set_control_registers () from /usr/lib/libdc1394.so.22<br>
> #5 0xaf79727e in dc1394_video_set_transmission ()<br>
> from /usr/lib/libdc1394.so.22<br>
> #6 0xaf930856 in CCdc1394_close () from /usr/lib/libcam_iface_dc1394.so<br>
> #7 0xaf931522 in delete_CCdc1394 () from /usr/lib/libcam_iface_dc1394.so<br>
> #8 0xb7bbe0b1 in delete_CamContext () from /usr/lib/libcam_iface_unity.so<br>
<br>
</div>Hmm, is this occurring with the same characteristics as the bug you<br>
wrote about earlier today? If this was happening right at camera<br>
initialization, I'd say to reduce the number of buffers and see if that<br>
helps. (Also re-plug the cameras and perhaps even reboot.) In fact, I'd<br>
still give that a try.<br>
<br>
But if this isn't right at the beginning of acquisition, I'm at a loss.<br>
It looks like the software is in the middle of attempting to close the<br>
camera on purpose. Any idea why that would be?<br>
<font color="#888888"><br>
-Andrew<br>
</font><div class="im"><br>
--<br>
Andrew D. Straw, Ph.D.<br>
California Institute of Technology<br>
<a href="http://www.its.caltech.edu/%7Eastraw/" target="_blank">http://www.its.caltech.edu/~astraw/</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">Motmot mailing list<br>
<a href="mailto:Motmot@code.astraw.com">Motmot@code.astraw.com</a><br>
<a href="http://code.astraw.com/cgi-bin/mailman/listinfo/motmot" target="_blank">http://code.astraw.com/cgi-bin/mailman/listinfo/motmot</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alice Anne Robie<br>California Institute of Technology<br>MC 138-78<br>1200 E. California Blvd.<br>Pasadena CA, 91125<br>(626) 395 4387<br>