19 Nov
2004
19 Nov
'04
10:14 p.m.
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?
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")
Permissions are correct for creating a fifo in the specified directory
(I ususally use /tmp).
'ser -c' reports 'ser.cfg' is ok.
The build of the 'ser' executable had no warnings; the only changes I
made were to Makefile.defs for the build environment and to 'locking.h':
66,69d65
< /* Addn'l defines -- MSG */
< #ifndef L_CRIT
< #define L_CRIT 2
< #endif
74d69
< #include <sys/errno.h>
These were necessary to complete the build.
I would appreciate any advice before I start peppering the code with
printfs.
Regards,
Michael Grigoni
Cybertheque Museum
22 Nov
22 Nov
6:53 a.m.
New subject: [Serusers] [Fwd: Ver 0.8.14 on OpenBSD/sparc segfaults]
On Nov 19, 2004 at 21:14, msg <michael.grigoni(a)cybertheque.org> wrote:
Hi Andrei,
Thanks very much for your reply.
Yes, I know. It's fixed on HEAD (/dev/urandom instead of /dev/random).
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?
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
11:42 a.m.
New subject: [Serusers] [Fwd: Ver 0.8.14 on OpenBSD/sparc segfaults]
I experimented over the weekend but was too tired to post the results :-)
> Strange, I've tried this on openbsd
3.2/x86 and it works.
> Andrei
Regards,
Michael Grigoni
Cybertheque Museum
>Here are the major problems:
>
>1. '-D' doesn't prevent forking to background
The single process which runs in the background does indeed work as
confirmed with tests using 'sipsak', but only on one interface
(loopback, unless it is explicitly specified in ser.cfg).
Without using command-line options:
"fork=yes" set in ser.cfg results on only a single process running in
the background
"fork=no" set in ser'cfg results in several processes starting followed
by a segfault (in one of them, the rest remain running):
(gdb) bt
#0 0x83a2584 in _atomic_lock ()
#1 0x83a2564 in _spinlock_debug ()
also, the fifo is created and 'serctl ps' will list the (2)
running processes, but this query will kill those
processes.
I tried running with various values of shmem (-m 4, 8, 12, etc) which
doesn't seem to change the behavior but changes the corefile size
somewhat. The machine has 16MB RAM and 500MB swap space -- for the
mixture of tasks it runs as a router (isakmpd, pf, snort, various
proxies) it never swaps; the swap space is there for big compiles
-- I vainly tried building OpenH323 and after eight days it gave up
on h323.cxx -- note that searching archives shows others have been
unable to build it on OpenBSD/sparc regardless of how much ram they have.
For my intended application (a few phones on our natted lan) I wouldn't
mind using just a single process with a very small memory footprint, but
it would need to listen on all of the interfaces and work with rtpproxy.
>2. no fifo is created regardless of the
'fifo=' statement in 'ser.cfg'
> or the command-line '-i' argument
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).
See above for strange behavior.
>Permissions are correct for creating a fifo in the specified directory
>(I ususally use /tmp).
See above -- fifo is created if "fork=no"
3:11 p.m.
New subject: [Serusers] [Fwd: Ver 0.8.14 on OpenBSD/sparc segfaults]
I increased the installed ram in this box to 40MB (all I had -- it maxes
out at 64MB anyway) with no change in the behavior; I tried running
with '-m 2, -m 4 -m 6 -m 8 and default (-m 32)' -- with '-m 2' two
processes start and there is no core dump but 'serctl ps' will kill
one of them and the other one hangs (in a loop accessing something in
the filesystem -- haven't traced it yet). This is with 'fork=no' in
ser.cfg. Only with 'fork=yes' will ser start (only one process) and
run stable. Regardless of the fork setting, ser will not remain in
the foreground.
Without using command-line options:
"fork=yes" set in ser.cfg results in only a single process running in
the background;
"fork=no" set in ser'cfg results in several processes starting followed
by a segfault (in one of them, the rest remain running):
(gdb) bt
#0 0x83a2584 in _atomic_lock ()
#1 0x83a2564 in _spinlock_debug ()
also, the fifo is created and 'serctl ps' will list the (2)
running processes, but this query will kill those
processes.
Michael
23 Nov
23 Nov
7:30 a.m.
New subject: [Serusers] [Fwd: Ver 0.8.14 on OpenBSD/sparc segfaults]
FWIW I put the makelog for the pthreads version (along with some
generated config files) in: ftp://ftp.cybertheque.org/pub/ser/
I'd gladly provide an account on this box to get ser running.
Regards,
Michael
7367
days inactive
7370
days old
4 comments
2 participants
participants (2)
-
Andrei Pelinescu-Onciul -
msg