I found that the error causing zmtrigger.pl to fail is the same in zm-alarm.pl and that it centers around Mmap. Both programs error in the same subroutine in Mapped.pm on the same line of code.
the calls start in zmtrigger.pl to the PERL modules which begins with checking "shared" or "mapped" and flows through Zoneminder.pm and Memory.pm to the subroutine zmMemGet in Mapped.pm. The sub zmMemGet at line 156 fails because the SCALAR variable $mmap
has no value and is empty.
Code: Select all
my $mmap = $monitor->{MMap};
if ( !$mmap || !$$mmap )
{
Error( sprintf( "Can't read from mapped memory for monitor '%d', gone away?"
, $monitor->{Id}
)
);
return( undef );
}
my $data = substr( $$mmap, $offset, $size );
return( $data );
}
in subroutine zmMemAttach in Mapped.pm line 114 may be failing which in turn causes line 123 which is
$monitor->{MMap} = \$mmap; to be empty and no value
Code: Select all
my $mmap = undef;
my $mmap_addr = mmap( $mmap, $size, PROT_READ|PROT_WRITE, MAP_SHARED, $MMAP );
if ( !$mmap_addr || !$mmap )
{
Error( sprintf( "Can't mmap to file '%s': $!\n", $mmap_file ) );
close( $MMAP );
return( undef );
}
$monitor->{MMapHandle} = $MMAP;
$monitor->{MMapAddr} = $mmap_addr;
$monitor->{MMap} = \$mmap;
}
return( !undef );
}
so it appears that something in the functions of Sys:: Mmap has changed.
I compared the running code using PERL -d and by following into the subroutines with "s" watched how zmtrigger.pl runs in ZM 1.30.4 and ZM 1.32 side by side to observe this behavior. by using the "p" in the debugger to print the variable values a SCALAR value is present when "p $monitor->{Mmap} right after the line 176 in Mapped.pm is executed in version 1.30.4 and is completely empty in ZM 1.32
