[Serusers] [Fwd: Ver 0.8.14 on OpenBSD/sparc segfaults]

Andrei Pelinescu-Onciul pelinescu-onciul at fokus.fraunhofer.de
Mon Nov 22 12:53:18 CET 2004


On Nov 19, 2004 at 21:14, msg <michael.grigoni at cybertheque.org> wrote:
> Hi Andrei,
> 
> Thanks very much for your reply.
> 
> >
> > Could you try the unstable (cvs HEAD) version? There are some SYSV lock
> >  fixes in it which were not backported to stable.
> >
> 
> I will try it soon and report results. .
> (note: all builds are done with OPENBSD_IS_AOUT=no
>        all tests are run as a non-priv user although running as root
>        produces identical behaviors but also occassionally huge core
>        dumps)
> 
> First I should mention the /dev/random on OpenBSD 3.2/sparc is reserved
> for non-existant hardware random number generators; I realize that
> you fall back to other methods but would it make sense to use one of
> the other available /dev/*random* devices in OpenBSD?

Yes, I know. It's fixed on HEAD (/dev/urandom instead of /dev/random).

> 
> Next, an experiment was to build it with 'posix sems' support;
> when run as 'ser -m 8 -E -ddddddddd' I get:
> 
>  0(32138) WARNING: could not read from /dev/random (5)
>  0(32138) read 0 from /dev/random
>  0(32138) seeding PRNG with 1100941542
>  0(32138) test random number 760286759
>  0(32138) ERROR: shm_mem_init: could not initialize lock
>  0(32138) shm_mem_destroy
>  0(32138) destroying the shared memory lock
>  0(32138) could not initialize shared memory pool, exiting...
> Too much shared memory demanded: 8388608
>  0(32138) shm_mem_destroy
>  0(32138) destroying the shared memory lock
> 
> note: '-m 1' in the command line produces the same behavior
> 
> /var/log/messages:
> 
> Nov 19 18:09:48 nat1 ser.posix-sems: WARNING: could not read from 
> /dev/random (5)
> Nov 19 18:09:48 nat1 ser.posix-sems: ERROR: shm_mem_init: could not 
> initialize lock
> Nov 19 18:09:48 nat1 ser.posix-sems: could not initialize shared memory 
> pool, exiting...
> 
> Next, I discovered that OpenBSD 3.2 pthreads exists and fixed problems 
> from the 2.x releases.  I was able to build 'ser' with pthreads using 
> the '-pthread' switch in the gcc command-line at link time.
> 
> Now, here are the results from running the 'pthreads' version:
> 
> $ ser -E -m 8 -ddddddddd
>  0(11853) WARNING: could not read from /dev/random (5)
>  0(11853) read 0 from /dev/random
>  0(11853) seeding PRNG with 1100922221
>  0(11853) test random number 2107379106
>  0(11853) shm_mem_init: success
>  0(11853) DEBUG: register_fifo_cmd: new command (print) registered
>  0(11853) DEBUG: register_fifo_cmd: new command (uptime) registered
>  0(11853) DEBUG: register_fifo_cmd: new command (version) registered
>  0(11853) DEBUG: register_fifo_cmd: new command (pwd) registered
>  0(11853) DEBUG: register_fifo_cmd: new command (arg) registered
>  0(11853) DEBUG: register_fifo_cmd: new command (which) registered
>  0(11853) DEBUG: register_fifo_cmd: new command (ps) registered
>  0(11853) DEBUG: register_fifo_cmd: new command (kill) registered
> Listening on
>               127.0.0.1 [127.0.0.1]:5060
>               10.0.0.100 [10.0.0.100]:5060
>               172.16.5.1 [172.16.5.1]:5060
>               216.251.177.106 [216.251.177.106]:5060
> Aliases: domesys.cybertheque.org:5060 nat1.dome1-wap1:5060 nat1:5060 
> nat1.cybertheque.net:5060 localhost:5060 localhost.cybertheque.net:5060
> 
> Here are the major problems:
> 
> 1. '-D' doesn't prevent forking to background
> 2. no fifo is created regardless of the 'fifo=' statement in 'ser.cfg'
>    or the command-line '-i' argument
> 3. no additional debug information is logged to syslog or stderr than
>    what is printed above (the only syslog message is "can't read from
>    /dev/random")

Did you comment out log_stderror and fork in ser.cfg? ser.cfg takes
precedence over the command line (so if you have fork=yes in ser.cfg,
 -D will be ignored).


> 
> Permissions are correct for creating a fifo in the specified directory
> (I ususally use /tmp).

Strange, I've tried this on openbsd 3.2/x86 and it works.


Andrei




More information about the sr-users mailing list