Camera OK during night segfaults at dawn with mjpg-streamer

[lingon]

I have a Raspberry Pi model B Revision : 0002 connected to a camera board of the very first batch released in May 2013 which is not over clocked. I have been running mjpg-streamer successfully with different input plugins on this hardware combination. Currently I'm trying to use the mjpg-streamer plugin input_raspicam.so on this hardware combination with the command
[code/usr/local/bin/mjpg_streamer -i "/usr/local/lib/input_raspicam.so -d 950 -x 960 -y 720 -ex night" -o "/usr/local/lib/output_http.so -p 8090 -w /usr/local/www" &][/code]
This works at night when there is no or very little light. At dawn or during daytime this command will fail with the error message Segmentation fault.

I have also a Raspberry Pi Model A Revision : 0008 with a camera board from the second batch.
I run the same mjpg-streamer plugin input_raspicam.so on the Raspberry Pi A without any problems.
I run exactly the same versions of mjpg_streamer, firmware and kernel on both of these the Raspberry Pi systems so the only difference is the hardware revisions of the Raspberry Pi boards. The PCB for the camera board was slightly changed, but otherwise I guess it is supposed to the same version in May and the second batch.

Is there some dependency of the Raspberry Pi model release version on the camera code that could explain this problem?

With strace I can see that it segfaults at this point
[code DBG(/home/pi/mjpg-streamer/mjpg-streamer-experimental/plugins/input_raspicam/input_raspicam.c, worker_thread(), 719): Encoder enabled, creating pool and connecting ports
DBG(/home/pi/mjpg-streamer/mjpg-streamer-experimental/plugins/input_raspicam/input_raspicam.c, worker_thread(), 777): Starting output
<unfinished ...>
+++ killed by SIGSEGV +++][/code]

[mors3]

Well (and I'm just guessing here) that command includes the switch 'night' which suggests to me that the feed monitor is optimised for low light levels, so when the light levels raise above the threshold it's outside the range and dropping the stream.

What I'd do is look at that switch to see what the other -ex parameters are, if there is a day one, run the same command in daytime using that and see if the stream maintains.

If it does, (purely to test) put in some error handling for seg faults, in which case switch the -ex parameter (and append to a custom log), then run that for 24 hours to see if it switches day/night mode twice.

[lingon]

Actually the -ex night option does not make any difference. If I try to start mjpg-streamer during daytime with or without that option it will segfault on my Revision 0002 Raspberry Pi Model B, but not on my Raspberry Pi Model A. For testing the -ex night is better now because the camera anyway only runs during night, so I can at least something. Maybe the raspicam input plugin is missing some header file needed for the Revision 0002 boards?

[jacksonliam]

Try the update I've done to the plugin, I've had it running for 6 days without issue on the code you're running though, the -ex options have caused me issues, so don't use those for now!

I'm not sure what's going on with all the /usr/local/ paths though, any reason you're not just running it from the source folder?

[jamesh]

I think that if the -ex option results in an exposure > about 350ms, then the system will lock up. Still investigating why.

[lingon]

I have tried out the latest version of the mjpg-streamer plugin input_raspicam. The latest version exposes the -q parameter for raspistill so that the effectively the size of the JPG-image can be varied. By experimenting with that I realized that the segmentation fault that I get is related to the size of the image. During night the image is mostly black and there is not very much information, so the JPG-image is small. During daytime the image is larger and it could be that some buffer space is exceeded which gives the segmentation fault.

Currently I'm running on the problematic Raspberry Pi the latest versions
uname -a
Linux rpicam 3.6.11+ #557 PREEMPT Wed Oct 2 18:49:09 BST 2013 armv6l GNU/Linux
vcgencmd version
Oct 18 2013 16:04:29
Copyright (c) 2012 Broadcom
version dbda126981820ea5681263042435388dddf65131 (tainted) (release)
raspistill
raspistill Camera App v1.3.4

Is there some difference between the Raspberry Pi Model B with 256 MB of RAM Revision : 0002 and the later revisions that should be taken into account in the mjpg-streamer plugin input_raspicam? On the Raspberry Pi Model B Revision : 0002 I have been able to run mjpg-streamer with the file input plugin without problems, so the problem is related to the input_raspicam and the original Revision : 0002 board.

My current workaround is to use -q 20 and in this way I can avoid the segmentation fault, but it would be great if the real cause of this problem could be understood and solved.

[jacksonliam]

I have tried out the latest version of the mjpg-streamer plugin input_raspicam. The latest version exposes the -q parameter for raspistill so that the effectively the size of the JPG-image can be varied. By experimenting with that I realized that the segmentation fault that I get is related to the size of the image. During night the image is mostly black and there is not very much information, so the JPG-image is small. During daytime the image is larger and it could be that some buffer space is exceeded which gives the segmentation fault.

Currently I'm running on the problematic Raspberry Pi the latest versions
uname -a
Linux rpicam 3.6.11+ #557 PREEMPT Wed Oct 2 18:49:09 BST 2013 armv6l GNU/Linux
vcgencmd version
Oct 18 2013 16:04:29
Copyright (c) 2012 Broadcom
version dbda126981820ea5681263042435388dddf65131 (tainted) (release)
raspistill
raspistill Camera App v1.3.4

Is there some difference between the Raspberry Pi Model B with 256 MB of RAM Revision : 0002 and the later revisions that should be taken into account in the mjpg-streamer plugin input_raspicam? On the Raspberry Pi Model B Revision : 0002 I have been able to run mjpg-streamer with the file input plugin without problems, so the problem is related to the input_raspicam and the original Revision : 0002 board.

My current workaround is to use -q 20 and in this way I can avoid the segmentation fault, but it would be great if the real cause of this problem could be understood and solved.

Hi,
Can you check the GPU memory split on both Pi's?
Does the firmware match on both?

I have every revision (B 256, B 512, A 256) and have not seen issue on any of them.

Could you test its not a power supply issue (the B draws more power) or SD card problem.

[lingon]

Can you check the GPU memory split on both Pi's?
Does the firmware match on both?

I have every revision (B 256, B 512, A 256) and have not seen issue on any of them.

Could you test its not a power supply issue (the B draws more power) or SD card problem.

This is from the Raspberry Pi A that works as expected
cat /proc/cpuinfo | grep Revision
Revision : 0008
grep gpu /boot/config.txt
gpu_mem=128
vcgencmd version
Oct 18 2013 16:04:29
Copyright (c) 2012 Broadcom
version dbda126981820ea5681263042435388dddf65131 (tainted) (release)

I have exactly the same settings and versions on my Raspberry Pi Model B
cat /proc/cpuinfo | grep Revision
Revision : 0002
grep gpu /boot/config.txt
gpu_mem=128
vcgencmd version
Oct 18 2013 16:04:29
Copyright (c) 2012 Broadcom
version dbda126981820ea5681263042435388dddf65131 (tainted) (release)

The problem is not due to the GPU memory split nor due to the GPU firmware revision.
Both machines have exactly the same type of SD-card, that is an 8 GB SanDisk Ultra 30 MB/s UHS 1 card.

The power supplies are identical on both machines. I cannot currently check the Raspberry Pi model B
voltage because it is some 60 km away. With the camera running I measure 4,82 V between TP1 and TP2 on the Raspberry Pi model A.

On the Raspberry Pi model B I have been running the camera without any segmentation fault problems in these configurations:
raspistill + python webserver + motion
raspistill + mjpg-streamer with file plugin + motion
v4l2 driver + motion
Only the combination
mjpg-streamer with raspicam plugin + motion gives the segmentation fault. To rule out any issue with the power supply I can test with a 5 V 2A USB power supply that I have, but based on the fact that the the camera runs OK in other configurations I doubt that it is an power supply issue. I'm not using over clocking on any Raspberry Pi.

[jacksonliam]

Hmmm i wonder if I'm not malloc'ing enough memory for the frame. That's the only thing I can think of. Surprising I haven't run into it before if that's the case.

Checkout the latest version (I've tripled the allocated memory) and give it a try https://github.com/jacksonliam/mjpg-streamer

[lingon]

Hmmm i wonder if I'm not malloc'ing enough memory for the frame. That's the only thing I can think of. Surprising I haven't run into it before if that's the case.

Checkout the latest version (I've tripled the allocated memory) and give it a try https://github.com/jacksonliam/mjpg-streamer

Thanks Liam! This change solved my problem when I upgraded to the latest version yesterday morning and removed the option "-q 20". The camera is now running the second day without any problems. Great!

I also agree that it is strange that others have not seen this problem. The latest picture that I got in 960x720 resolution has a size of 772 045 bytes. Looking at some old test pictures in full resolution 2592 x 1944, I find the largest file size to be 4 645 261 bytes.

[jacksonliam]

Hmmm i wonder if I'm not malloc'ing enough memory for the frame. That's the only thing I can think of. Surprising I haven't run into it before if that's the case.

Checkout the latest version (I've tripled the allocated memory) and give it a try https://github.com/jacksonliam/mjpg-streamer

Thanks Liam! This change solved my problem when I upgraded to the latest version yesterday morning and removed the option "-q 20". The camera is now running the second day without any problems. Great!

I also agree that it is strange that others have not seen this problem. The latest picture that I got in 960x720 resolution has a size of 772 045 bytes. Looking at some old test pictures in full resolution 2592 x 1944, I find the largest file size to be 4 645 261 bytes.

Ah, the old buffer was only 691,200 bytes for 960x720, however 2592x1944 would've given you a 5,038,848 byte buffer. I've trippled these so we should never have to worry even with -q 100!