# zoneminder 1.25.0_5 on freebsd 10 - zmu - SIGSEGV



## n0p (Oct 8, 2014)

Hello,

At the moment I am in trouble with a fresh FreeBSD 10 i386 zoneminder 1.25.0_5 (compiled with ports tree). I have no idea how to proceed - so you are my last hope 

The binary zmu of the standard-zoneminder i386 port compilation fails with SIGSEGV. The other binaries work - zmc, zma. I can access the web interface, watch the capture-preview-streams, but when I access the zones, which are dependent on zmu, the application fails. On the CLI I get a 


```
# zmu
Segmentation fault (core dumped)
```

Does anyone know about this error or is facing similar issues?

Some additional infos:


```
/usr/local/bin/zmu:
	libthr.so.3 => /lib/libthr.so.3 (0x280e9000)
	libz.so.6 => /lib/libz.so.6 (0x2810b000)
	libbz2.so.4 => /usr/lib/libbz2.so.4 (0x2811f000)
	libswscale0.so.1 => /usr/local/lib/ffmpeg0/libswscale0.so.1 (0x2812f000)
	libavdevice0.so.1 => /usr/local/lib/ffmpeg0/libavdevice0.so.1 (0x28156000)
	libavformat0.so.1 => /usr/local/lib/ffmpeg0/libavformat0.so.1 (0x2815a000)
	libavcodec0.so.1 => /usr/local/lib/ffmpeg0/libavcodec0.so.1 (0x28241000)
	libavutil0.so.1 => /usr/local/lib/ffmpeg0/libavutil0.so.1 (0x28c5e000)
	libx264.so.136 => /usr/local/lib/libx264.so.136 (0x28c7a000)
	libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x28ddc000)
	libcrypto.so.7 => /lib/libcrypto.so.7 (0x28e48000)
	libjpeg.so.11 => /usr/local/lib/libjpeg.so.11 (0x28fd3000)
	libmysqlclient.so.18 => /usr/local/lib/mysql/libmysqlclient.so.18 (0x29008000)
	libstdc++.so.6 => /usr/local/lib/gcc48/libstdc++.so.6 (0x29344000)
	libm.so.5 => /lib/libm.so.5 (0x29430000)
	libc.so.7 => /lib/libc.so.7 (0x29452000)
	libgcc_s.so.1 => /usr/local/lib/gcc48/libgcc_s.so.1 (0x295bc000)
	libxvidcore.so.4 => /usr/local/lib/libxvidcore.so.4 (0x295d8000)
	libvpx.so.1 => /usr/local/lib/libvpx.so.1 (0x296ed000)
	libvorbisenc.so.2 => /usr/local/lib/libvorbisenc.so.2 (0x2988b000)
	libvorbis.so.4 => /usr/local/lib/libvorbis.so.4 (0x2990d000)
	libogg.so.8 => /usr/local/lib/libogg.so.8 (0x29935000)
	libtheoraenc.so.1 => /usr/local/lib/libtheoraenc.so.1 (0x2993b000)
	libtheoradec.so.1 => /usr/local/lib/libtheoradec.so.1 (0x2996b000)
	libschroedinger-1.0.so.11 => /usr/local/lib/libschroedinger-1.0.so.11 (0x2997c000)
	libopencv_core.so.2 => /usr/local/lib/libopencv_core.so.2 (0x29a24000)
	libopencv_imgproc.so.2 => /usr/local/lib/libopencv_imgproc.so.2 (0x29c33000)
	libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x29eab000)
	libc++.so.1 => /usr/lib/libc++.so.1 (0x29f31000)
	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x29fdb000)
	liborc-0.4.so.0 => /usr/local/lib/liborc-0.4.so.0 (0x29ff2000)
```


```
FreeBSD 10.0-RELEASE-p9 FreeBSD 10.0-RELEASE-p9 #0: Mon Sep 15 14:32:29 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
```


```
mprotect(0x2812f000,155648,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
mprotect(0x2812f000,155648,PROT_READ|PROT_EXEC)	 = 0 (0x0)
mprotect(0x28156000,12288,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
mprotect(0x28156000,12288,PROT_READ|PROT_EXEC)	 = 0 (0x0)
mprotect(0x2815a000,921600,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
mprotect(0x2815a000,921600,PROT_READ|PROT_EXEC)	 = 0 (0x0)
mprotect(0x28241000,4984832,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
mmap(0x0,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 705118208 (0x2a074000)
mprotect(0x28241000,4984832,PROT_READ|PROT_EXEC) = 0 (0x0)
mprotect(0x28c5e000,94208,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
mprotect(0x28c5e000,94208,PROT_READ|PROT_EXEC)	 = 0 (0x0)
mprotect(0x28c7a000,942080,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
mprotect(0x28c7a000,942080,PROT_READ|PROT_EXEC)	 = 0 (0x0)
mprotect(0x28e48000,1519616,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
munmap(0x2a078000,28672)			 = 0 (0x0)
mmap(0x0,69632,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 705134592 (0x2a078000)
mprotect(0x28e48000,1519616,PROT_READ|PROT_EXEC) = 0 (0x0)
mprotect(0x29424000,16384,PROT_READ)		 = 0 (0x0)
mprotect(0x295d8000,659456,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0)
mprotect(0x295d8000,659456,PROT_READ|PROT_EXEC)	 = 0 (0x0)
sysarch(0xa,0xbfbfd3a4,0x280d8fe8,0x280d52b0,0xbfbfd3c8,0x280c07a3) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)		 = 0 (0x0)
readlink("/etc/malloc.conf",0xbfbfcb3f,1024)	 ERR#22 'Invalid argument'
issetugid(0x2958721a,0xbfbfcb3f,0x400,0x0,0x6d62696c,0x632e7061) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 705204224 (0x2a089000)
munmap(0x2a089000,4194304)			 = 0 (0x0)
mmap(0x0,8384512,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 705204224 (0x2a089000)
munmap(0x2a089000,3633152)			 = 0 (0x0)
munmap(0x2a800000,557056)			 = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)		 = 0 (0x0)
__sysctl(0xbfbfce84,0x2,0xbfbfcebc,0xbfbfceb8,0x295d37e0,0xe) = 0 (0x0)
__sysctl(0xbfbfcebc,0x2,0xbfbfcf60,0xbfbfcf64,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)		 = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)		 = 0 (0x0)
getpid()					 = 88294 (0x158e6)
__sysctl(0xbfbfcee0,0x2,0x2810ac14,0xbfbfcee8,0x0,0x0) = 0 (0x0)
__sysctl(0xbfbfce04,0x2,0xbfbfce3c,0xbfbfce38,0x280fdcc8,0xd) = 0 (0x0)
__sysctl(0xbfbfce3c,0x3,0x28109ad8,0xbfbfcee8,0x0,0x0) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 713031680 (0x2a800000)
thr_self(0x2a803080,0x28109ad8,0xbfbfcee8,0x0,0x0,0x0) = 0 (0x0)
mmap(0xbf9fe000,4096,PROT_NONE,MAP_ANON,-1,0x0)	 = -1080041472 (0xbf9fe000)
rtprio_thread(0x0,0x188ae,0xbfbfcea0,0x1000,0xbf9fe000,0x28101920) = 0 (0x0)
sysarch(0xa,0xbfbfcea8,0x280d8fe8,0x281016d4,0xbfbfcefc,0x280fa80b) = 0 (0x0)
sigaction(32,{ 0x280f5780 SA_SIGINFO ss_t },0x0) = 0 (0x0)
sigprocmask(SIG_UNBLOCK,0x0,0x0)		 = 0 (0x0)
_umtx_op(0xbfbfce7c,0x3,0x1,0x0,0x0,0xffffffff)	 = 0 (0x0)
mprotect(0x0,0,PROT_NONE)			 = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)		 = 0 (0x0)
SIGNAL 11 (SIGSEGV)
process exit, rval = 0
```

Thank you very very much - any help or hint is appreciated. 

Thanks,
n0p


----------



## n0p (Dec 17, 2014)

Hi,

Is really no one able to help me out here? I would be really happy with every hint I will get.

I updated to FreeBSD 10.1 i386 with zoneminder 1.25.0_6 - unfortunately I there is the same behavior as before. When I access the zone option in the web interface there is a core dump of the binary /usr/local/bin/zmu. The same happens when I start the binary directly on the CLI.

Any idea? Is nobody using zoneminder on FreeBSD?

Regards,

n0p


----------



## wblock@ (Dec 17, 2014)

It might just be that other users are not here in the forums (or are here, but don't know the answer), and asking on the freebsd-questions mailing list would reach more people.


----------



## n0p (Dec 18, 2014)

Thank you - you are right, I think I will give it a try.


----------



## Jimmy (Dec 18, 2014)

I have used this in the past on FreeBSD 8 / (possibly?) 9 but not extensively although I don't recall any functional problems.  There was an old thread (2 years or more) in the zoneminder forums specific to getting this working on FreeBSD, perhaps there will be some information there as to a similar issue and some pointers?


----------



## pboehmer (Dec 18, 2014)

You are not the only one.  Been fighting with the same issue for the past couple of weeks.  Since motion detection works and I can get still shots in the event reporting, I've put it on the back burner trying to troubleshoot the issue.  I'd love to hear if you find a solution.


----------



## n0p (Dec 22, 2014)

Thank you. I will keep you informed.


----------



## datentod (Jan 3, 2015)

Got the same issue. Tried for half a day to fix it to no avail.


```
root@zmt:/secvid/data/Images # file zmu.core
zmu.core: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), FreeBSD-style, from 'zmu'
root@zmt:/secvid/data/Images # ls -atlr
total 103308
drwxr-xr-x  12 root  www        512 Jan  2 14:16 ..
-rw-r--r--   1 root  www      69363 Jan  2 14:37 1
drwxrwxrwx   2 www   www        512 Jan  2 14:38 .
-rw-------   1 www   www  105660416 Jan  2 19:36 zmu.core
root@zmt:/secvid/data/Images # gdb
GNU gdb 6.1.1 [FreeBSD]
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 "amd64-marcel-freebsd".
(gdb) core zmu.core
Core was generated by `zmu'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb)
(gdb)
(gdb) quit
root@zmt:/secvid/data/Images # /usr/local/bin/zmu
Segmentation fault (core dumped)
root@zmt:/secvid/data/Images # uname -a
FreeBSD zmt.kilsol.com 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@zmt:/secvid/data/Images #
```


----------



## datentod (Jan 3, 2015)

It worked before on FreeBSD 9.x (don't remember exact version now). I migrated in a hurry to 10.1 without checking the zones and can't revert to old config anymore...


----------



## pboehmer (Jan 5, 2015)

I had some time over the holidays to try to debug zmu without much luck.  I recompiled my entire test system (core+ports) with:


```
WITH_DEBUG=yes
```
in my /etc/make.conf in an attempt to track down where the problem is, but I believe threading is keeping me from successfully debugging the program.  This is probably the second time that I had ever used `gdb` so I am probably missing something.


----------

