Hi,
when starting openser 1.3.1 it doesn't really start, but stops after processing a SIGILL. When perfoming
strace -f /usr/local/sbin/openser
I get the following output (these are only the last few lines):
time([1208951399]) = 1208951399 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:49:59 /usr/local/"..., 147, MSG_NOSIGNAL) = 147 --- SIGILL (Illegal instruction) @ 0 (0) --- Process 12746 detached
I've compiled openser from source on the same machine. When starting openser with -V everything works just fine. Output:
version: openser 1.3.1-notls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 3590 2008-01-28 17:46:56Z bogdan_iancu $ main.c compiled on 10:47:24 Apr 23 2008 with gcc 3.4.5
So I guessed the problem could occur inside a module. I removed auth.so and auth_db.so from my config file, but openser still doesn't start. But, it doesn't receive a SIGILL anymore, but SIGTERM. Output from strace:
time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<139>Apr 23 13:54:21 /usr/local/"..., 103, MSG_NOSIGNAL) = 103 kill(0, SIGTERM) = 0 --- SIGTERM (Terminated) @ 0 (0) --- sigreturn() = ? (mask now []) time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
[...]
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:54:21 /usr/local/"..., 113, MSG_NOSIGNAL) = 113 munmap(0xb5f58000, 33554432) = 0 exit_group(-1) = ? Process 12752 detached
Any ideas how to fix this problem?
Thx, Christian
Hi Christian,
Any logs from openser during startup? if not, try to enable debug (debug=6) and see where is stops.
Regards, Bogdan
Christian Koch wrote:
Hi,
when starting openser 1.3.1 it doesn't really start, but stops after processing a SIGILL. When perfoming
strace -f /usr/local/sbin/openser
I get the following output (these are only the last few lines):
time([1208951399]) = 1208951399 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:49:59 /usr/local/"..., 147, MSG_NOSIGNAL) = 147 --- SIGILL (Illegal instruction) @ 0 (0) --- Process 12746 detachedI've compiled openser from source on the same machine. When starting openser with -V everything works just fine. Output:
version: openser 1.3.1-notls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 3590 2008-01-28 17:46:56Z bogdan_iancu $ main.c compiled on 10:47:24 Apr 23 2008 with gcc 3.4.5So I guessed the problem could occur inside a module. I removed auth.so and auth_db.so from my config file, but openser still doesn't start. But, it doesn't receive a SIGILL anymore, but SIGTERM. Output from strace:
time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<139>Apr 23 13:54:21 /usr/local/"..., 103, MSG_NOSIGNAL) = 103 kill(0, SIGTERM) = 0 --- SIGTERM (Terminated) @ 0 (0) --- sigreturn() = ? (mask now []) time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 [...] stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:54:21 /usr/local/"..., 113, MSG_NOSIGNAL) = 113 munmap(0xb5f58000, 33554432) = 0 exit_group(-1) = ? Process 12752 detachedAny ideas how to fix this problem?
Thx, Christian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Bogdan,
when logging to syslog these are the last lines I get:
Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: registering stats for usrloc Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: register MI for usrloc Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: initializing module registrar Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: INFO:registrar:mod_init: initializing... Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <load_sl>(0) in module sl [/usr/local/lib/openser/modules/] Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <ul_bind_usrloc>(1) in module usrloc [/usr/local/lib/openser/modules/] Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: registering stats for registrar Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: initializing module auth Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: INFO:auth:mod_init: initializing... Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <load_sl>(0) in module sl [/usr/local/lib/openser/modules/]
All other messages I get are either DBG or INFO, no errors. But now I tried something different. I've set "fork=no", and now I'm getting a corefile. Backtrace of gdb is:
(gdb) bt #0 0x0012ff8f in mod_init () at auth_mod.c:200 #1 0x080ab61e in init_mod (m=0x8165048) at sr_module.c:461 #2 0x080ab3f5 in init_mod (m=0x81650e8) at sr_module.c:456 #3 0x080ab3f5 in init_mod (m=0x8165188) at sr_module.c:456 #4 0x080ab3f5 in init_mod (m=0x8165228) at sr_module.c:456 #5 0x080ab3f5 in init_mod (m=0x81652c8) at sr_module.c:456 #6 0x080ab3f5 in init_mod (m=0x8165368) at sr_module.c:456 #7 0x080ab3f5 in init_mod (m=0x8165408) at sr_module.c:456 #8 0x080ab3f5 in init_mod (m=0x81654a8) at sr_module.c:456 #9 0x080ab3f5 in init_mod (m=0x8165548) at sr_module.c:456 #10 0x080ab3f5 in init_mod (m=0x8165618) at sr_module.c:456 #11 0x080ab3f5 in init_mod (m=0x81656b8) at sr_module.c:456 #12 0x080684a7 in main (argc=1, argv=0xbff668b4) at main.c:1355 (gdb)
Looks like calling init_mod() recursively. I didn't study the openser code, but this backtrace looks strange to me. If anybody is interested in the whole corefile, please mail me directly. I don't want to post such a large file to the list.
Thanks a lot for your help, Christian
Bogdan-Andrei Iancu schrieb:
Hi Christian,
Any logs from openser during startup? if not, try to enable debug (debug=6) and see where is stops.
Regards, Bogdan
Christian Koch wrote:
Hi,
when starting openser 1.3.1 it doesn't really start, but stops after processing a SIGILL. When perfoming
strace -f /usr/local/sbin/openser
I get the following output (these are only the last few lines):
time([1208951399]) = 1208951399 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:49:59 /usr/local/"..., 147, MSG_NOSIGNAL) = 147 --- SIGILL (Illegal instruction) @ 0 (0) --- Process 12746 detached
I've compiled openser from source on the same machine. When starting openser with -V everything works just fine. Output:
version: openser 1.3.1-notls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 3590 2008-01-28 17:46:56Z bogdan_iancu $ main.c compiled on 10:47:24 Apr 23 2008 with gcc 3.4.5So I guessed the problem could occur inside a module. I removed auth.so and auth_db.so from my config file, but openser still doesn't start. But, it doesn't receive a SIGILL anymore, but SIGTERM. Output from strace:
time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<139>Apr 23 13:54:21 /usr/local/"..., 103, MSG_NOSIGNAL) = 103 kill(0, SIGTERM) = 0 --- SIGTERM (Terminated) @ 0 (0) --- sigreturn() = ? (mask now []) time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
[...] stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:54:21 /usr/local/"..., 113, MSG_NOSIGNAL) = 113 munmap(0xb5f58000, 33554432) = 0 exit_group(-1) = ? Process 12752 detached
Any ideas how to fix this problem?
Thx, Christian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Christian,
The line the trace refer at is:
sec_rand[i] = 32 + (int)(95.0 * rand() / (RAND_MAX + 1.0));
I suspect the rand() function, as there were some previous reports about it....:(
Could you try alter the code and replace the rand() with some number just to see if it won't crash?
Regards, Bogdan
Christian Koch wrote:
Hi Bogdan,
when logging to syslog these are the last lines I get:
Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: registering stats for usrloc Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: register MI for usrloc Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: initializing module registrar Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: INFO:registrar:mod_init: initializing... Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <load_sl>(0) in module sl [/usr/local/lib/openser/modules/] Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <ul_bind_usrloc>(1) in module usrloc [/usr/local/lib/openser/modules/] Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: registering stats for registrar Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: initializing module auth Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: INFO:auth:mod_init: initializing... Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <load_sl>(0) in module sl [/usr/local/lib/openser/modules/]All other messages I get are either DBG or INFO, no errors. But now I tried something different. I've set "fork=no", and now I'm getting a corefile. Backtrace of gdb is:
(gdb) bt #0 0x0012ff8f in mod_init () at auth_mod.c:200 #1 0x080ab61e in init_mod (m=0x8165048) at sr_module.c:461 #2 0x080ab3f5 in init_mod (m=0x81650e8) at sr_module.c:456 #3 0x080ab3f5 in init_mod (m=0x8165188) at sr_module.c:456 #4 0x080ab3f5 in init_mod (m=0x8165228) at sr_module.c:456 #5 0x080ab3f5 in init_mod (m=0x81652c8) at sr_module.c:456 #6 0x080ab3f5 in init_mod (m=0x8165368) at sr_module.c:456 #7 0x080ab3f5 in init_mod (m=0x8165408) at sr_module.c:456 #8 0x080ab3f5 in init_mod (m=0x81654a8) at sr_module.c:456 #9 0x080ab3f5 in init_mod (m=0x8165548) at sr_module.c:456 #10 0x080ab3f5 in init_mod (m=0x8165618) at sr_module.c:456 #11 0x080ab3f5 in init_mod (m=0x81656b8) at sr_module.c:456 #12 0x080684a7 in main (argc=1, argv=0xbff668b4) at main.c:1355 (gdb)Looks like calling init_mod() recursively. I didn't study the openser code, but this backtrace looks strange to me. If anybody is interested in the whole corefile, please mail me directly. I don't want to post such a large file to the list.
Thanks a lot for your help, Christian
Bogdan-Andrei Iancu schrieb:
Hi Christian,
Any logs from openser during startup? if not, try to enable debug (debug=6) and see where is stops.
Regards, Bogdan
Christian Koch wrote:
Hi,
when starting openser 1.3.1 it doesn't really start, but stops after processing a SIGILL. When perfoming
strace -f /usr/local/sbin/openser
I get the following output (these are only the last few lines):
time([1208951399]) = 1208951399 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:49:59 /usr/local/"..., 147, MSG_NOSIGNAL) = 147 --- SIGILL (Illegal instruction) @ 0 (0) --- Process 12746 detached
I've compiled openser from source on the same machine. When starting openser with -V everything works just fine. Output:
version: openser 1.3.1-notls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 3590 2008-01-28 17:46:56Z bogdan_iancu $ main.c compiled on 10:47:24 Apr 23 2008 with gcc 3.4.5So I guessed the problem could occur inside a module. I removed auth.so and auth_db.so from my config file, but openser still doesn't start. But, it doesn't receive a SIGILL anymore, but SIGTERM. Output from strace:
time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<139>Apr 23 13:54:21 /usr/local/"..., 103, MSG_NOSIGNAL) = 103 kill(0, SIGTERM) = 0 --- SIGTERM (Terminated) @ 0 (0) --- sigreturn() = ? (mask now []) time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
[...] stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:54:21 /usr/local/"..., 113, MSG_NOSIGNAL) = 113 munmap(0xb5f58000, 33554432) = 0 exit_group(-1) = ? Process 12752 detached
Any ideas how to fix this problem?
Thx, Christian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Bogdan,
I tried replacing the rand() function in that line, but afterwards I got a core file at another line. Still with SIGILL.
But I think I've found a solution: In "Makefile.defs", for i386 with gcc 3.x I removed the following line (line 592):
-march=$(CPU_TYPE)
CPU_TYPE would be set to "prescott" in that case, but the manpage of gcc states prescott is "Improved version of Intel Pentium4 CPU...". My machine is a Pentium III, so it doesn't understand the P4 code generated by gcc. I recompiled openser without "-march" and it seems everything works fine now. I think the Makefile still needs to be fixed for the other architectures and gcc versions.
Regards, Christian
Bogdan-Andrei Iancu schrieb:
Hi Christian,
The line the trace refer at is:
sec_rand[i] = 32 + (int)(95.0 * rand() / (RAND_MAX + 1.0));
I suspect the rand() function, as there were some previous reports about it....:(
Could you try alter the code and replace the rand() with some number just to see if it won't crash?
Regards, Bogdan
Christian Koch wrote:
Hi Bogdan,
when logging to syslog these are the last lines I get:
Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: registering stats for usrloc Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: register MI for usrloc Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: initializing module registrar Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: INFO:registrar:mod_init: initializing... Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <load_sl>(0) in module sl [/usr/local/lib/openser/modules/] Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <ul_bind_usrloc>(1) in module usrloc [/usr/local/lib/openser/modules/] Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: registering stats for registrar Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:init_mod: initializing module auth Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: INFO:auth:mod_init: initializing... Apr 23 16:12:02 192 /usr/local/sbin/openser[12817]: DBG:core:find_cmd_export_t: found <load_sl>(0) in module sl [/usr/local/lib/openser/modules/]All other messages I get are either DBG or INFO, no errors. But now I tried something different. I've set "fork=no", and now I'm getting a corefile. Backtrace of gdb is:
(gdb) bt #0 0x0012ff8f in mod_init () at auth_mod.c:200 #1 0x080ab61e in init_mod (m=0x8165048) at sr_module.c:461 #2 0x080ab3f5 in init_mod (m=0x81650e8) at sr_module.c:456 #3 0x080ab3f5 in init_mod (m=0x8165188) at sr_module.c:456 #4 0x080ab3f5 in init_mod (m=0x8165228) at sr_module.c:456 #5 0x080ab3f5 in init_mod (m=0x81652c8) at sr_module.c:456 #6 0x080ab3f5 in init_mod (m=0x8165368) at sr_module.c:456 #7 0x080ab3f5 in init_mod (m=0x8165408) at sr_module.c:456 #8 0x080ab3f5 in init_mod (m=0x81654a8) at sr_module.c:456 #9 0x080ab3f5 in init_mod (m=0x8165548) at sr_module.c:456 #10 0x080ab3f5 in init_mod (m=0x8165618) at sr_module.c:456 #11 0x080ab3f5 in init_mod (m=0x81656b8) at sr_module.c:456 #12 0x080684a7 in main (argc=1, argv=0xbff668b4) at main.c:1355 (gdb)Looks like calling init_mod() recursively. I didn't study the openser code, but this backtrace looks strange to me. If anybody is interested in the whole corefile, please mail me directly. I don't want to post such a large file to the list.
Thanks a lot for your help, Christian
Bogdan-Andrei Iancu schrieb:
Hi Christian,
Any logs from openser during startup? if not, try to enable debug (debug=6) and see where is stops.
Regards, Bogdan
Christian Koch wrote:
Hi,
when starting openser 1.3.1 it doesn't really start, but stops after processing a SIGILL. When perfoming
strace -f /usr/local/sbin/openser
I get the following output (these are only the last few lines):
time([1208951399]) = 1208951399 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:49:59 /usr/local/"..., 147, MSG_NOSIGNAL) = 147 --- SIGILL (Illegal instruction) @ 0 (0) --- Process 12746 detached
I've compiled openser from source on the same machine. When starting openser with -V everything works just fine. Output:
version: openser 1.3.1-notls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 3590 2008-01-28 17:46:56Z bogdan_iancu $ main.c compiled on 10:47:24 Apr 23 2008 with gcc 3.4.5So I guessed the problem could occur inside a module. I removed auth.so and auth_db.so from my config file, but openser still doesn't start. But, it doesn't receive a SIGILL anymore, but SIGTERM. Output from strace:
time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<139>Apr 23 13:54:21 /usr/local/"..., 103, MSG_NOSIGNAL) = 103 kill(0, SIGTERM) = 0 --- SIGTERM (Terminated) @ 0 (0) --- sigreturn() = ? (mask now []) time([1208951661]) = 1208951661 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
[...] stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837,...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0 send(3, "<143>Apr 23 13:54:21 /usr/local/"..., 113, MSG_NOSIGNAL) = 113 munmap(0xb5f58000, 33554432) = 0 exit_group(-1) = ? Process 12752 detached
Any ideas how to fix this problem?
Thx, Christian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
On Monday 28 April 2008, Christian Koch wrote:
I tried replacing the rand() function in that line, but afterwards I got a core file at another line. Still with SIGILL.
But I think I've found a solution: In "Makefile.defs", for i386 with gcc 3.x I removed the following line (line 592):
-march=$(CPU_TYPE)
CPU_TYPE would be set to "prescott" in that case, but the manpage of gcc states prescott is "Improved version of Intel Pentium4 CPU...". My machine is a Pentium III, so it doesn't understand the P4 code generated by gcc. I recompiled openser without "-march" and it seems everything works fine now. I think the Makefile still needs to be fixed for the other architectures and gcc versions.
Hi Christian,
i think the correct statement for (a recent) 3.X gcc would be either 'mcpu=prescott' or 'mtune=prescott'. I don't know why march is used in this case, for the x86_64 case its correct. Then the compiler will only optimize for this special processor, but the code will nevertheless run on i386 machines too.
The 'prescott' type is unfortunally not available on older gcc, so i used 'pentium4' instead. I'll make a fix on svn, could you perhaps test this?
Thank you,
Henning
Henning Westerholt schrieb:
Hi Christian,
i think the correct statement for (a recent) 3.X gcc would be either 'mcpu=prescott' or 'mtune=prescott'. I don't know why march is used in this case, for the x86_64 case its correct. Then the compiler will only optimize for this special processor, but the code will nevertheless run on i386 machines too.
The 'prescott' type is unfortunally not available on older gcc, so i used 'pentium4' instead. I'll make a fix on svn, could you perhaps test this?
Thank you,
Henning
Hi Henning,
you're right. The manpage of gcc says for mtune:
While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used.
But as I have a Pentium III, I wouldn't benefit of "mtune=prescott", although the compiled code will run on my machine, of course. I think the correct way would be to have a configure script determining the CPU type and using that type for mtune (I know, that would be a lot of work....). When you fixed the Makefile in SVN, just tell me, so I can test it.
Christian
On Monday 28 April 2008, Christian Koch wrote:
you're right. The manpage of gcc says for mtune:
While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used.But as I have a Pentium III, I wouldn't benefit of "mtune=prescott", although the compiled code will run on my machine, of course. I think the correct way would be to have a configure script determining the CPU type and using that type for mtune (I know, that would be a lot of work....). When you fixed the Makefile in SVN, just tell me, so I can test it.
Hi Christian,
sure, this would be the best way. But as both gcc 3.X and pentium3 are not that much in use anymore, i think that 'pentium4' as optimization works for the most people at the moment.
I just commited the fix for the trunk and 1.3 branch.
Henning
Hi Henning,
Thanks for the fix. I guess there are several compile optimization that are a bit too aggressive, so most sure this will not be the last fix in this area ;).
Regards, Bogdan
Christian Koch wrote:
Henning Westerholt schrieb:
I just commited the fix for the trunk and 1.3 branch.
I've just downloaded and compiled the latest snapshot (openser-1.3.x-svn-20080428-141101.tgz). It seems to run fine.
Thanks for your support, Christian
-
Bogdan-Andrei Iancu -
Christian Koch -
Henning Westerholt