Backtrace 0: /usr/lib/cgi-bin/nph-zms(_Z14zm_die_handleriP9siginfo_tPv+0x62) [0x80d03f2]]

[marcmerlin]

Is this a bug with the package, or potentially the underlying code?

zms[3667]: INF [Authenticated user 'root'] zms[3667]: WAR [Shared data not initialised by capture daemon, some query functions may not be available or produce invalid results for monitor wansview] zms[3667]: ERR [Got signal 7 (Bus error), crashing] zms[3667]: ERR [Signal address is 0xdf379004, from 0x80824a7] zms[3667]: ERR [Backtrace 0: /usr/lib/cgi-bin/nph-zms(_Z14zm_die_handleriP9siginfo_tPv+0x62) [0x80d03f2]] zms[3667]: ERR [Backtrace 1: linux-gate.so.1(kernel_rt_sigreturn+0) [0xf7722a50]] zms[3667]: ERR [Backtrace 2: /usr/lib/cgi-bin/nph-zms(_ZNK7Monitor6GetFPSEv+0x17) [0x80824a7]] zms[3667]: ERR [Backtrace 3: /usr/lib/cgi-bin/nph-zms(_ZN13MonitorStream9runStreamEv+0x45) [0x808dd65]] zms[3667]: ERR [Backtrace 4: /usr/lib/cgi-bin/nph-zms(main+0xac8) [0x805b8e8]] zms[3667]: ERR [Backtrace 5: /lib/i386-linux-gnu/i686/cmov/libc.so.6(libc_start_main+0xf3) [0xf55c3a63]] zms[3667]: ERR [Backtrace 6: /usr/lib/cgi-bin/nph-zms() [0x805c0e9]] zms[3667]: INF [Backtrace complete, please execute the following command for more information] zms[3667]: INF [addr2line -e /usr/lib/cgi-bin/nph-zms 0x80d03f2 0xf7722a50 0x80824a7 0x808dd65 0x805b8e8 0xf55c3a63 0x805c0e9]

addr2line -e /usr/lib/cgi-bin/nph-zms 0x80d03f2 0xf7722a50 0x80824a7 0x808dd65 0x805b8e8 0xf55c3a63 0x805c0e9 ??:? ??:0 ??:? ??:? ??:? ??:0 ??:?

Bugs: mailto:marillat@deb-multimedia.org Architecture: i386 Source: zoneminder-dmo Version: 1.28.1-dmo13

[marcmerlin]

I've been trying to debug this further. I have 13 cameras, the others work fine, but cameras 13 and 14 I just added keep failing with WAR [Shared data not initialised by capture daemon, some query functions may not be available or produce invalid results for monitor wansview]

I'm really not sure why those two aren't starting. I copied all the camera data from cam14 to cam1, and then the camera works totally fine when accessed as cam1.

Looking at startup logs: zmdc[21744]: INF ['zmc -m 13' starting at 15/11/05 20:00:31, pid = 22481] zmdc[22481]: INF ['zmc -m 13' started at 15/11/05 20:00:31] zmdc[21744]: INF ['zmc -m 13' crashed, signal 6]

strace -f /usr/bin/zmc -m 13 gives write(4, "Q\2\0\0\3select Id, Name, Type, Func"..., 597) = 597 read(4, "\1\0\0\0011,\0\0\2\3def\2zm\10Monitors\10Monito"..., 16384) = 3309 mmap2(NULL, 6221824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff1f11000 mmap2(NULL, 2076672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff1d16000 mmap2(NULL, 6221824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff1727000 open("/dev/shm/zm.mmap.13", O_RDWR|O_CREAT, 0600) = 6 fstat64(6, {st_mode=S_IFREG|0600, st_size=311041360, ...}) = 0 mmap2(NULL, 311041360, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_LOCKED, 6, 0) = -1 EAGAIN (Resource temporarily unavailable) mmap2(NULL, 311041360, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0xffffffffdee85000 brk(0xedb6000) = 0xedb6000 --- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRERR, si_addr=0xee0bd000} ---

[connortechnology]

This normally means that you are out of memory. It may mean that you are out of space on your ram-fs /dev/shm area where the mmap files are located. Use df to see how much space you have left there.

[marcmerlin]

connortechnology: your crystal ball is working very well, congrats :)

Now, the error reporting here is non existent unfortunately. Can we keep this as a bug until zoneminder is fixed to detect this problem and output a reasonable error message for it?

Thanks.

[knight-of-ni]

The error message you posted is spot on. You just need to learn how to read the message. It might not be not easy at first. We've all been there, and we can certainly help you along the way. In time, you'll get it.

The message in your post states zoneminder couldn't mmap, which is why @connortechnology responded with the answer he gave. There is no magic there, just experience.

The trouble with your request for a "reasonable" error message is that everyone has their own different opinion on just what "reasonable" means. We've got plenty of people willing to tell us what they think we should be working on, but when it comes time to help out they want us to do the work for them. Since our current work model is on a volunteer basis, requests to change something based on personal preference are not being accepted.

If you would like to improve the output to something to your liking, then feel free to submit a pull request. We can then have a discussion on that.

[marcmerlin]

@knnniggett your call, but don't you think that code crashing with bus error isn't a normal exit path? It's pretty much telling me that it is a bug and to report it with addr2line output If I wasn't supposed to think that the code crashed with a bug, I recommend modifying it so that it doesn't crash with a bus error (zms) As for zmc, it also crashed with a bus error and didn't output any information as to why it failed or that it was related to /dev/shm. Only strace gave a clue here. Your point still remains that it's OSS and I can learn the code and submit a pull request, but I was hoping that not having zms and zmc both crash with a bus error was a bit more than just personal preference :)

[marcmerlin]

@knnniggett and @connortechnology : I forgot to add that while I feel a bit bad of reporting a problem with my system which I thought was a bug due to the code crashes, I am thankful for your reply. Also, while I don't have time to contribute to this specific project, I did make a donation to it as suggested, since the project has been quite useful to me. So, thanks again.

[connortechnology]

I think we can and should do better in this case, but I've actually tried to detect this and so far have failed.

Mostly I've seen this on my raspberry pi which is of course extremely limited in ram.

I think we would have to get the available disk space for the tmpfs area for our mmap files and test to see if it will fit. I think this is the only way, because actually trying to mmap crashes us.

We can afford to be a little pedantic here, because this would only happen once per program lifetime.

So.. I'm ok with treating this as an actual bug/ui improvement. Especially if it means that we won't get an endless stream of people having the same problem reporting it as a bug to us.

[marcmerlin]

@connortechnology that sounds fair. For what it's worth, I hit this problem when I added my 3rd 1080p camera and zoneminder started needing more than 1.5GB of shm space (which is what my system had by default when it booted). There is a decent chance that as people get more HD cams, they're likely to hit limits too, just can't tell you how often or how many people this will impact. You can decide to reopen this bug if you think that makes sense since it's currently marked as closed.