[ZCM] [ZC] 1301/11 Comment "SIGBUS on sparc64"
Collector: Zope Bugs, Features,
and Patches ...
zope-coders-admin at zope.org
Sat Apr 9 03:50:08 EDT 2005
Issue #1301 Update (Comment) "SIGBUS on sparc64"
Status Pending, Zope/bug critical
To followup, visit:
http://www.zope.org/Collectors/Zope/1301
==============================================================
= Comment - Entry #11 by ajung on Apr 9, 2005 3:50 am
This is issue still unresolved? Otherwise it will be closed soon.
________________________________________
= Comment - Entry #10 by tim_one on Apr 28, 2004 1:06 am
heidegger, this issue is about a SIGBUS crash on a 64-bit machine. If you have some problem with initgroup() other than that, please open a new issue for it (mixing issues in a single report is a good way to ensure that neither of them will make progress <0.5 wink>).
________________________________________
= Comment - Entry #9 by heidegger on Apr 28, 2004 12:59 am
NetBSD i386 'current' (1.6ZI) shows this behaviour too when an 'effective user' is set in $INSTANCE/etc/zope.conf:
trollboy /usr/local/zope27 # bin/runzope &
[1] 1904
trollboy /usr/local/zope27 # ------
2004-04-27T01:49:15 INFO(0) ZServer HTTP server started at Tue Apr 27 01:49:15 2004
Hostname: trollboy.host_obfuscated.org
Port: 8088
Traceback (most recent call last):
File "/usr/local/lib/Zope2.7/lib/python/Zope/Startup/run.py", line 49, in ?
run()
File "/usr/local/lib/Zope2.7/lib/python/Zope/Startup/run.py", line 19, in run
start_zope(opts.configroot)
File "/usr/local/lib/Zope2.7/lib/python/Zope/Startup/__init__.py", line 48, in start_zope
starter.dropPrivileges()
File "/usr/local/lib/Zope2.7/lib/python/Zope/Startup/__init__.py", line 203, in dropPrivileges
return dropPrivileges(self.cfg)
File "/usr/local/lib/Zope2.7/lib/python/Zope/Startup/__init__.py", line 347, in dropPrivileges
initgroups.initgroups(effective_user, gid)
AttributeError: 'module' object has no attribute 'initgroups'
________________________________________
= Comment - Entry #8 by GenericPlayer on Apr 27, 2004 12:16 am
The only place it seems to be used is when starting zope as root and having it drop privileges, it uses initgroups to find out the gid to setgid to in __init__.py. Maybe add a config option to zope.conf for effective-group to go with the effective-user option?
________________________________________
= Comment - Entry #7 by tim_one on Apr 26, 2004 11:49 pm
I agree -- but then this code doesn't even try to run on Windows, so what do I care <wink>.
________________________________________
= Comment - Entry #6 by mcdonc on Apr 26, 2004 11:34 pm
Thanks for explaining Tim! I think it would be time better spent to remove this module than to fix the bug unless somebody can explain why it exists and what its benefit is.
________________________________________
= Comment - Entry #5 by tim_one on Apr 26, 2004 11:26 pm
Good eye, Chris! I see that the C code in Zope's initgroups_initgroups() starts with
gid_t gid;
if (!PyArg_ParseTuple(args, "sl:initgroups", &username, &gid))
The "l" format code makes Python treat it like a C long, which is probably 8 bytes on this box. If sizeof(gid_t) < 8 on this box, then, the PyArg_ParseTuple() call will write beyond the space allocated for gid. Hilarity ensues, if so.
________________________________________
= Comment - Entry #4 by mcdonc on Apr 26, 2004 10:43 pm
Aha. Perhaps uncomment anything that does "import initgroups" from the Zope source and anything that uses that module. This is an odd module that I personally never thought was necessary and should likely be removed. Zope should run fine without it.
________________________________________
= Comment - Entry #3 by GenericPlayer on Apr 26, 2004 10:32 pm
If I run it under ktrace, the last things I get before it crashing is this:
10010 python2.3 CALL open(0xffffffffffff11f0,0,0)
10010 python2.3 NAMI "/usr/local/zope/lib/python/initgroups.so"
10010 python2.3 RET open 8
10010 python2.3 CALL fcntl(0x8,0x3,0)
10010 python2.3 RET fcntl 0
10010 python2.3 CALL fcntl(0x8,0x4,0x4)
10010 python2.3 RET fcntl 0
10010 python2.3 CALL fstat(0x8,0xffffffffffff0ce0)
10010 python2.3 RET fstat 0
10010 python2.3 CALL open(0xffffffffffff11f0,0,0)
10010 python2.3 NAMI "/usr/local/zope/lib/python/initgroups.so"
10010 python2.3 RET open 9
10010 python2.3 CALL read(0x9,0xfffffffffffefa50,0x1000)
10010 python2.3 GIO fd 9 read 4096 bytes
----snip the data it read----
10010 python2.3 RET read 4096/0x1000
10010 python2.3 CALL mmap(0,0x602000,0,0x2,0x9,0,0)
10010 python2.3 RET mmap 1456504832/0x56d08000
10010 python2.3 CALL mmap(0x56d08000,0x2000,0x5,0x12,0x9,0,0)
10010 python2.3 RET mmap 1456504832/0x56d08000
10010 python2.3 CALL mmap(0x56e08000,0x2000,0x1,0x12,0x9,0,0)
10010 python2.3 RET mmap 1457553408/0x56e08000
10010 python2.3 CALL mmap(0x56f08000,0x2000,0x3,0x12,0x9,0,0)
10010 python2.3 RET mmap 1458601984/0x56f08000
10010 python2.3 CALL mmap(0x57008000,0x2000,0x7,0x12,0x9,0,0)
10010 python2.3 RET mmap 1459650560/0x57008000
10010 python2.3 CALL mmap(0x57208000,0x2000,0x3,0x12,0x9,0,0)
10010 python2.3 RET mmap 1461747712/0x57208000
10010 python2.3 CALL mmap(0x57308000,0x2000,0x3,0x12,0x9,0,0)
10010 python2.3 RET mmap 1462796288/0x57308000
10010 python2.3 CALL close(0x9)
10010 python2.3 RET close 0
10010 python2.3 CALL mprotect(0x56e08000,0xd18,0x3)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL mprotect(0x56d08000,0xcf4,0x7)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL mprotect(0x56e08000,0xd18,0x1)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL mprotect(0x56d08000,0xcf4,0x5)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL mprotect(0x57208f00,0x2000,0x1)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL mprotect(0x57008000,0x2000,0x5)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL sigprocmask(0x1,0xffffffff)
10010 python2.3 RET sigprocmask 0
10010 python2.3 CALL mprotect(0x57008000,0x2000,0x7)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL mprotect(0x57008000,0x2000,0x5)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL sigprocmask(0x3,0)
10010 python2.3 RET sigprocmask -65793/0xfffefeff
10010 python2.3 CALL fstat(0x8,0xffffffffffff0fd0)
10010 python2.3 RET fstat 0
10010 python2.3 CALL fcntl(0x8,0x3,0)
10010 python2.3 RET fcntl 4
10010 python2.3 CALL fcntl(0x8,0x4,0)
10010 python2.3 RET fcntl 0
10010 python2.3 CALL close(0x8)
10010 python2.3 RET close 0
10010 python2.3 CALL sigprocmask(0x1,0xffffffff)
10010 python2.3 RET sigprocmask 0
10010 python2.3 CALL mprotect(0x57008000,0x2000,0x7)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL mprotect(0x57008000,0x2000,0x5)
10010 python2.3 RET mprotect 0
10010 python2.3 CALL sigprocmask(0x3,0)
10010 python2.3 RET sigprocmask -65793/0xfffefeff
10010 python2.3 PSIG SIGBUS SIG_DFL code 0 addr=0x489fe0f0 trapno=0
10010 python2.3 PSIG SIGBUS SIG_DFL code 0 addr=0x0 trapno=0
10010 python2.3 NAMI "python2.3.core"
________________________________________
= Comment - Entry #2 by mcdonc on Apr 26, 2004 5:35 pm
Hmm.. maybe you could start Zope under strace to see what it's trying to do when it crashes?
________________________________________
= Request - Entry #1 by GenericPlayer on Apr 26, 2004 5:21 pm
I made a zope instance, and edited the etc/zope.conf file. Setting the effective user to _zope and running bin/runzope as root causes zope to crash with sigbus. If I just su to _zope and run bin/runzope its fine. I am not entirely sure how to tell if this is a zope bug or a python bug, since the backtrace is all ?? and I can't seem to get zope compiled with -ggdb.
==============================================================
More information about the Zope-Collector-Monitor
mailing list