BUG: Segfault with Motion 3.2.4 and Axis 206M

Running Motion 3.2.4 with a single camera, an Axis 206M, with its maximum view size of 1280x1024.

I think this is a reincarnation of my older, rejected bug--do I need to send this to the ffmpeg developers?? Or is it something Motion is doing?

Test case

I'm using the very newest ffmpeg I can get from Dag for RHAS3, http://dag.wieers.com/packages/ffmpeg/ffmpeg-0.4.9-0.20041110.3.1.el3.rf.i386.rpm

Here is how I ran Motion 3.2.4:

cd /etc/motion
ulimit -c unlimited
/usr/bin/motion -n -d 100 -c /etc/motion/deleteme1.conf

This is the last thing I got on the console:

[1] Calculated frame time 187641.750000
[1] Found image header record
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
[1] processing jpeg image - content length 336251
[1] Calculated frame time 185741.968750
[1] Found image header record
[1] Calculated frame time 184461.078125
[1] Found image header record
[1] processing jpeg image - content length 331959
[1] Calculated frame time 183760.265625
[1] Found image header record
[1] Calculated frame time 183999.437500
[1] Found image header record
[1] processing jpeg image - content length 332999
[1] Calculated frame time 185480.296875
[1] Found image header record
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
./deleteme1: line 3: 23345 Segmentation fault      (core dumped) /usr/bin/motion -n -d 100 -c /etc/motion/deleteme1.conf

Looking at the core file, I see the following.

[root@swlx12 motion]# gdb /usr/bin/motion -c core.23345
GNU gdb Red Hat Linux (6.3.0.0-1.62rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

Core was generated by `/usr/bin/motion -n -d 100 -c /etc/motion/deleteme1.conf'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libjpeg.so.62
Reading symbols from /usr/lib/libavformat.so...done.
Loaded symbols for /usr/lib/libavformat.so
Reading symbols from /usr/lib/libavcodec.so...done.
Loaded symbols for /usr/lib/libavcodec.so
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libfaad.so.0...done.
Loaded symbols for /usr/lib/libfaad.so.0
Reading symbols from /usr/lib/libfaac.so.0...done.
Loaded symbols for /usr/lib/libfaac.so.0
Reading symbols from /usr/lib/libxvidcore.so.4...done.
Loaded symbols for /usr/lib/libxvidcore.so.4
Reading symbols from /usr/lib/libpostproc.so.0...done.
Loaded symbols for /usr/lib/libpostproc.so.0
Reading symbols from /usr/lib/libmp3lame.so.0...done.
Loaded symbols for /usr/lib/libmp3lame.so.0
Reading symbols from /usr/lib/libvorbis.so.0...done.
Loaded symbols for /usr/lib/libvorbis.so.0
Reading symbols from /usr/lib/libvorbisenc.so.2...done.
Loaded symbols for /usr/lib/libvorbisenc.so.2
Reading symbols from /usr/lib/libogg.so.0...done.
Loaded symbols for /usr/lib/libogg.so.0
#0  0x005df262 in free () from /lib/tls/libc.so.6
(gdb) bt
#0  0x005df262 in free () from /lib/tls/libc.so.6
#1  0x00c497b6 in av_freep (arg=0x6a3cd8) at utils.c:110
#2  0x00c4c7b4 in free_duplicate_context (s=0x8382290) at mpegvideo.c:474
#3  0x00c4db95 in MPV_common_end (s=0x8382290) at mpegvideo.c:795
#4  0x00c4e815 in MPV_encode_end (avctx=0x837dd28) at mpegvideo.c:1265
#5  0x00c4a276 in avcodec_close (avctx=0x837dd28) at utils.c:546
#6  0x08060038 in ffmpeg_close ()
#7  0x080591c9 in event_ffmpeg_closefile ()
#8  0x0805937a in event ()
#9  0x0804c5ce in motion_loop ()
#10 0x00537dd8 in start_thread () from /lib/tls/libpthread.so.0
#11 0x0064ad1a in clone () from /lib/tls/libc.so.6
(gdb)

Environment

Motion version:	3.2.4
ffmpeg version:	0.4.9-pre1, build 4730
Shared libraries:	ffmpeg
Server OS:	Redhat AS 3, kernel 2.4.21-27.0.2.ELsmp

-- PeterS - 19 Dec 2005

Follow up

I just recompiled with Developer Flags turned on. I noticed the following in the debug output. Note the "fake EOI inserted" and "Corrupt JPEG data" messages.

[1] processing jpeg image - content length 332983
[1] Found image header record
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
[1] Calculated frame time 233770.843750
[1] Found image header record
[1] **fake EOI inserted**
[1] Corrupt JPEG data: premature end of data segment
[1] vid_return_code 10
[1] processing jpeg image - content length 331467
[1] processing jpeg image - content length 332983
[1] Calculated frame time 239577.656250
[1] ***new pic delay successful***

Could this ultimately be a Netcam issue which is causing a segfault related to the camera image size changing?

-- PeterS - 19 Dec 2005

I'm almost totally convinced this crash is being caused by mjpeg errors or our interpretation of the stream from the camera. I'm seeing frame errors in the AVIs Motion is producing.. Every once in a while there will be a glitch in the file, this glitch is either being fed to ffmpeg via Motion or is being generated by ffmpeg on its own.. I'll add images to my Motion test to see if it actually is during the capture or avi production..

-- PeterS - 19 Dec 2005

Interestingly enough, with the Developer Flags turned on, Motion does not appear to be crashing. However I have an image here that is corrupt which was captured by Motion and what looks like a debug log that describes an error associated with it ("Corrupt JPEG data").

[1] Calculated frame time 173036.625000
[1] processing jpeg image - content length 323419
[1] Found image header record
[1] Corrupt JPEG data: 124 extraneous bytes before marker 0xd9
[1] Calculated frame time 188625.562500
[1] Found image header record
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
[1] Calculated frame time 185202.000000
[1] Found image header record
[1] Calculated frame time 186962.000000
[1] File of type 1 saved to: /var/www/html/cam/ac-dc1-630-1/2005/12/19/181524-02.jpg
[1] Found image header record

-- PeterS - 20 Dec 2005

It crashed overnight. The last thing on the console was this.

[1] processing jpeg image - content length 331827
[1] Calculated frame time 175662.359375
[1] Found image header record
[1] Calculated frame time 177548.921875
[1] Found image header record
[1] processing jpeg image - content length 331519
[1] Calculated frame time 176639.828125
[1] Found image header record
[1] Calculated frame time 172285.750000
[1] processing jpeg image - content length 329931
[1] Found image header record
[1] Potential split boundary - 4095 chars flushed, 1 re-positioned
[1] Calculated frame time 176391.875000
[1] Found image header record
./deleteme1: line 3: 32657 Segmentation fault      (core dumped) /usr/bin/motion -n -d 100 -c /etc/motion/deleteme1.conf

The backtrace for the core is as follows.

[root@swlx12 motion]# gdb /usr/bin/motion -c core.32657
GNU gdb Red Hat Linux (6.3.0.0-1.62rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

Core was generated by `/usr/bin/motion -n -d 100 -c /etc/motion/deleteme1.conf'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libjpeg.so.62
Reading symbols from /usr/lib/libavformat.so...done.
Loaded symbols for /usr/lib/libavformat.so
Reading symbols from /usr/lib/libavcodec.so...done.
Loaded symbols for /usr/lib/libavcodec.so
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libfaad.so.0...done.
Loaded symbols for /usr/lib/libfaad.so.0
Reading symbols from /usr/lib/libfaac.so.0...done.
Loaded symbols for /usr/lib/libfaac.so.0
Reading symbols from /usr/lib/libxvidcore.so.4...done.
Loaded symbols for /usr/lib/libxvidcore.so.4
Reading symbols from /usr/lib/libpostproc.so.0...done.
Loaded symbols for /usr/lib/libpostproc.so.0
Reading symbols from /usr/lib/libmp3lame.so.0...done.
Loaded symbols for /usr/lib/libmp3lame.so.0
Reading symbols from /usr/lib/libvorbis.so.0...done.
Loaded symbols for /usr/lib/libvorbis.so.0
Reading symbols from /usr/lib/libvorbisenc.so.2...done.
Loaded symbols for /usr/lib/libvorbisenc.so.2
Reading symbols from /usr/lib/libogg.so.0...done.
Loaded symbols for /usr/lib/libogg.so.0
#0  0x00400262 in free () from /lib/tls/libc.so.6
(gdb) bt
#0  0x00400262 in free () from /lib/tls/libc.so.6
#1  0x001317b6 in av_freep (arg=0x4c4cd8) at utils.c:110
#2  0x001347b4 in free_duplicate_context (s=0xb4e01aa0) at mpegvideo.c:474
#3  0x00135b95 in MPV_common_end (s=0xb4e01aa0) at mpegvideo.c:795
#4  0x00136815 in MPV_encode_end (avctx=0xb4e01448) at mpegvideo.c:1265
#5  0x00132276 in avcodec_close (avctx=0xb4e01448) at utils.c:546
#6  0x08060038 in ffmpeg_close ()
#7  0x080591c9 in event_ffmpeg_closefile ()
#8  0x0805937a in event ()
#9  0x0804c5ce in motion_loop ()
#10 0x007f4dd8 in start_thread () from /lib/tls/libpthread.so.0
#11 0x0046bd1a in clone () from /lib/tls/libc.so.6
(gdb)

-- PeterS - 20 Dec 2005

I'm going to follow the ffmpeg debugging guidelines and see what I can find out..

-- PeterS - 20 Dec 2005

I am wondering.

I think you have maybe 3 errors.

First you get errors when you fetch the frames from the netcam. It is remote? Can you safely fetch 5 frames per second in the large resolution? Does it work at a lower framerate?

Second - Motion seems to still not being good enough at rejecting non-complete or corrupted jpegs or jpeg frames. We need to avoid that any garbage is ever sent to ffmpeg.

Last. I wonder if we even have the 2nd error. You run with a very large frame size. Bigger than what you normally get from a capture card.

ffmpeg is very poorly documented and I have not even tried to go behind the code. But there is one thing in Motion and in most programs using libavframe. We all use the only documentation there is... a code example. And in this code exampe there is a buffer size which is hard coded to 200 kbytes. Maybe this is not enough. I do not know if this output buffer can take fractions at a time. I would think it needs to hold a full frame. Why not try an experiment.

In the motion sources - file ffmpeg.c lines 331-332 (motion-3.2.4)

ffmpeg->video_outbuf_size = 200000;
ffmpeg->video_outbuf = mymalloc(ffmpeg->video_outbuf_size);

Now are these 200000 enough with your framesize?

Why not try 400000?

If it works then we need to define this based on width and height. Maybe just in 2-3 jumps. We cannot know the exact size since the size depends both on contents, quality and size.

It may not be important but since we are desperate - give it a try.

-- KennethLavrsen - 20 Dec 2005

Interestingly enough, I get slightly different results with the CVS ffmpeg:

(gdb) bt
#0  0x000c3500 in ?? ()
#1  0x00c94f7f in av_log_default_callback (ptr=0x96a83d8, level=1, fmt=0xe73398 "picture size invalid (%ux%u)\n", vl=0x19cd1fc "\b") at utils.c:1247
#2  0x00c95047 in av_vlog (avcl=0x96a83d8, level=157975512, fmt=0x96a83d8 "\200\204j\t ¡\a", vl=0x96a83d8 "\200\204j\t ¡\a") at utils.c:1268
#3  0x00c95016 in av_log (avcl=0x96a83d8, level=157975512, fmt=0x96a83d8 "\200\204j\t ¡\a") at utils.c:1262
#4  0x00c93b0e in avcodec_check_dimensions (av_log_ctx=0x96a83d8, w=8, h=13189168) at utils.c:258
#5  0x00c9439d in avcodec_open (avctx=0x96a83d8, codec=0x1) at utils.c:828
#6  0x0805fd5a in ffmpeg_open ()
#7  0x08058beb in event_ffmpeg_newfile ()
#8  0x0805937a in event ()
#9  0x0804b040 in motion_detected ()
#10 0x0804d2e3 in motion_loop ()
#11 0x0065bdd8 in start_thread () from /lib/tls/libpthread.so.0
#12 0x0021dd1a in clone () from /lib/tls/libc.so.6

That is an odd message, "picture size invalid". I'm not sure if it crashed while it was creating a log entry. I've created a bug report at ffmpeg-devel...

What is very very odd is it does not crash on a different test system, under Fedora Core 4 using ffmpeg-0.4.9-0.lvn.0.18.20050801.4. At least I haven't seen it crash yet.

-- PeterS - 20 Dec 2005

Another oddity I'm seeing on the Fedora Core 4 system that hasn't crashed yet--"encoded frame too large" messages, I'm getting at least one of these PER .avi generated.

[1] Potential split boundary - 4095 chars flushed, 1 re-positioned
[1] File of type 8 saved to: /files/ac-test2/2005/12/20/185134.avi
[1] Calculated frame time 174082.828125
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/185133-03.jpg
[1] Found image header record
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/185134-00.jpg
[1] Calculated frame time 168482.140625
[mpeg4 @ 0x61d790]encoded frame too large
[1] Found image header record

Sometimes this message occurs more than once per .avi generated.

[1] Found image header record
[1] File of type 8 saved to: /files/ac-test2/2005/12/20/182850.avi
[1] Calculated frame time 190607.406250
[1] Found image header record
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/182849-01.jpg
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/182849-02.jpg
[1] Calculated frame time 186594.671875
[1] Found image header record
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
[mpeg4 @ 0x61d790]encoded frame too large
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/182849-03.jpg
[1] Calculated frame time 180213.312500
[1] Found image header record
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/182850-00.jpg
[mpeg4 @ 0x61d790]encoded frame too large
[1] processing jpeg image - content length 349335

-- PeterS - 21 Dec 2005

I just recompiled with the 400000 test you recommended, and I'm noticing a change, it may be too early to tell. "Corrupt JPEG data" messages have replaced the "encoded frame too large" messages. Keep in mind this is on my FC4 test box. Not sure if I should try this on my production box quite yet (the one that crashes.)

[1] processing jpeg image - content length 344895
[1] File of type 8 saved to: /files/ac-test2/2005/12/20/190914.avi
[1] Calculated frame time 169858.875000
[1] Found image header record
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/190913-03.jpg
[1] Calculated frame time 164462.593750
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/190914-00.jpg
[1] Found image header record
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/190914-01.jpg
[1] Calculated frame time 171617.734375
[1] File of type 1 saved to: /files/ac-test2/2005/12/20/190914-02.jpg
[1] processing jpeg image - content length 341671
[1] Found image header record
[1] **fake EOI inserted**
[1] Corrupt JPEG data: premature end of data segment
[1] vid_return_code 10
[1] Potential split boundary - 1447 chars flushed, 1 re-positioned

-- PeterS - 21 Dec 2005

I'm intrigued by the frequent occurrence of the log entry "Potential split boundary" (it looks as if it's always occurring right around the trouble spot). During the writing and debugging of the current netcam code, this area of the code gave me the most problems. I was fairly confident that all of those problems had been overcome, but seeing your logs make me very uncomfortable.

The basic problem being addressed in this part of the code is the fact that the received data is a "stream", and the code must be able to separate that stream into separate jpeg frames. For extra safety, two separate methods are used whenever possible. First, if there is a "Content Length" that is used. Second (and in any event) the code watches for the "boundary string".

The trouble starts from the fact that the stream data actually arrives in "chunks", which are determined by the network "recv" instruction (so, for practical purposes, we can say they are of random size). If the "boundary string" should happen to be split across two separate chunks, the code "notices" (at the end of the first chunk) that the string might be present, but has to read the next chunk before it can be certain. To make the string comparison easy, the code attempts to accept all of the data up to the start of the (possible) boundary string fragment, then re-position the (possible) fragment to the beginning of the buffer, and read in the next "chunk" from the stream.

Unfortunately, there are many potential problems with this approach, details of which can be found in the comments within the code (netam.c, around line 866). If I were to write this section of code over again (and I may yet be forced into doing just that) I would try to find a better way.

I shall continue to try to reproduce the problem - what I would really like is a captured file for which the problem is "reproducible", and I'll see if I can produce that. In the meantime, just treat my remarks as "interesting comment".

-- BillBrack - 22 Dec 2005

Bill, that is some very interesting and revealing information. Btw, please refer to the message I sent to the mailing list about having a test cam setup currently, you can use this to test with if you'd like.

-- PeterS - 22 Dec 2005

In case anyone improves the netcam code note that Angel did a change to netcam.c in the latest BSD patch (has nothing to do with this problem).

So use http://www.lavrsen.dk/sources/motion-daily/motion-20051223-082332.tar.gz or later for up2date sources.

-- KennethLavrsen - 23 Dec 2005

Setup the latest CVS version yesterday and experienced the same crash as previous.. motion-20051227-051001.tar.gz

[root@swlx12 motion]# gdb -c core.3114 /tmp/2/usr/bin/motion
GNU gdb Red Hat Linux (6.3.0.0-1.62rh)
Copyright 2004 Free Software Foundation, Inc.
<snip>
Core was generated by `/usr/bin/motion -n -d 100'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libjpeg.so.62
Reading symbols from /usr/lib/libavformat.so...done.
Loaded symbols for /usr/lib/libavformat.so
Reading symbols from /usr/lib/libavcodec.so...done.
Loaded symbols for /usr/lib/libavcodec.so
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libfaad.so.0...done.
Loaded symbols for /usr/lib/libfaad.so.0
Reading symbols from /usr/lib/libfaac.so.0...done.
Loaded symbols for /usr/lib/libfaac.so.0
Reading symbols from /usr/lib/libxvidcore.so.4...done.
Loaded symbols for /usr/lib/libxvidcore.so.4
Reading symbols from /usr/lib/libpostproc.so.0...done.
Loaded symbols for /usr/lib/libpostproc.so.0
Reading symbols from /usr/lib/libmp3lame.so.0...done.
Loaded symbols for /usr/lib/libmp3lame.so.0
Reading symbols from /usr/lib/libvorbis.so.0...done.
Loaded symbols for /usr/lib/libvorbis.so.0
Reading symbols from /usr/lib/libvorbisenc.so.2...done.
Loaded symbols for /usr/lib/libvorbisenc.so.2
Reading symbols from /usr/lib/libogg.so.0...done.
Loaded symbols for /usr/lib/libogg.so.0
#0  0x002dc2a7 in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0  0x002dc2a7 in _int_free () from /lib/tls/libc.so.6
#1  0x002db278 in free () from /lib/tls/libc.so.6
#2  0x007687b6 in av_freep (arg=0x39fcd8) at utils.c:110
#3  0x007698e9 in avcodec_default_free_buffers (s=0x90a9518) at utils.c:781
#4  0x0076d815 in MPV_encode_end (avctx=0x90a9518) at mpegvideo.c:1265
#5  0x00769276 in avcodec_close (avctx=0x90a9518) at utils.c:546
#6  0x08060493 in ffmpeg_close ()
#7  0x080591d9 in event_ffmpeg_closefile ()
#8  0x0805938a in event ()
#9  0x0804c57e in motion_loop ()
#10 0x00f81dd8 in start_thread () from /lib/tls/libpthread.so.0
#11 0x00346d1a in clone () from /lib/tls/libc.so.6
(gdb)

This crash is obviously from a bug in Motion tickling something bugged in ffmpeg. I'll try it on my newer ffmpeg desktop test machine, again.

-- PeterS - 28 Dec 2005

I may wind up closing/cancelling this bug soon. On the system where I was seeing crashes, I pulled down the latest CVS of ffmpeg, rolled an RPM of it using the ffmpeg.spec from Dag's site, then I updated all the RPMs on the system to Redhat's latest for AS 3... And I even re-compiled the motion-20051227-051001.tar.gz to exclude the developer flags. Believe it or not it has been stable for the past 6 hours or so.. I'll let it run through the weekend and see if anything bad happens.. If not, I'll probably just cancel this due to the fact that once the netcam bugs got fixed I believe the only problem remaining that I was seeing was probably either glibc or gcc related. Once I updated those, I'm not seeing any problems. I'll keep everyone updated.. I hate it when this happens but perhaps it is for the best..

-- PeterS - 31 Dec 2005

I'm closing this bug since I've had Motion up over the weekend--it is stable now that the netcam bug was fixed and also since I've fully updated my gcc.. I'm no longer getting crashes.

-- PeterS - 02 Jan 2006

Fix record