Motion - Bug Report 2005x 02x 19x 175939

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
I Attachment Action Size Date Who Comment
gdb.core.27025.2005-02-20-2153pm2005-02-20-2153pm gdb.core.27025.2005-02-20-2153pm manage 4 K 21 Feb 2005 - 08:50 UnknownUser  
motion.confconf motion.conf manage 15 K 19 Feb 2005 - 20:28 UnknownUser working motion.conf
motion.crash.gdb.outout motion.crash.gdb.out manage 13 K 19 Feb 2005 - 18:15 UnknownUser two gdb outputs
thread1.confconf thread1.conf manage 4 K 19 Feb 2005 - 18:12 UnknownUser usb logitech webcam
thread2.confconf thread2.conf manage 3 K 19 Feb 2005 - 18:12 UnknownUser remote rf linked ntsc cam
Topic revision: r6 - 13 Aug 2005, KennethLavrsen
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.