BUG: segmentation fault
motion has been running fine. got a segmentation fault this am. discovered it some hours later. re-ran motion. almost instant seg fault. and again, similarly.
i will attach gdb output from debugging sessions. please tell me what else you'd like.
of note: this cam runs off a 1.5 gHz remote link. today there is significant interference of some sort, visible in tvtime monitoring of the image. i have seen similar interference before, but it seemingly did not result in seg faults. i can provide an avi of interference shortly before first seg fault if you want to see it.
edit: i kept thinking that something to do with persistent data must be causing motion to now consistently crash, when it had worked for a long time before. i tried removing the daily mpg file and it made no difference. the only other persistent data i could find was the conf files. when i looked at motion.conf it had been changed. i believe it was via the web interface. i manually edited it to be more rational and suddenly motion is working again. i am attaching the working version. my current guess is that something caused motion to crash. and the motion.conf file caused it to continue to crash. i have a feeling that the initial crash may have been caused by a very dirty signal from the rf link to the camera.
edit: sheesh. i think i have overwritten the original motion.conf attachment with the edited one. is there any way to retrieve the original one i'd attached?
--
JohnBray - 20 Feb 2005
Click on the 'manage'-button in the attachment form to retrieve older versions
--
JoergWeber - 20 Feb 2005
edit: ahhh...joerg! you are wonderful!
i rebuilt motion without optimization, so the gdb output should be real, per angel's recommendation. i just attached one gdp output file. it seems typical. they all seem to crash in one of the ffmpeg routines. i believe this is all related to motion receiving bad data from the tv card due to the RF link between the camera and the card sometimes going flakey. still working that problem; various antenna configurations appear to make little difference.
i can attach an mpeg of similar video that did happen to not cause a crash if you're interested in looking at it.
the question in my mind is whether motion should be detecting this kind of condition and not sending it to ffmpeg, or ffmepg should be more robust? just thinking out loud.
--
JohnBray - 21 Feb 2005
Test case
Environment
Motion version: |
3.2.1-snap 1 |
ffmpeg version: |
0.4.9-0.20041110.3.1.fc3.rf |
Shared libraries: |
curl, ffmpeg, mysql, postgresql |
Server OS: |
2.6.10-1.760_FC3 |
--
JohnBray - 19 Feb 2005
Follow up
Fix record
Not seen again
--
KennethLavrsen - 13 Aug 2005