Zope 2.7.0 crash on FreeBSD 5.2
Hello, I've recently installed Python 2.3.4 and Zope 2.7.0 on FreeBSD 5.2 and moved my Data.fs over with no apparent problems (at first). Previously I was using Python 2.3.3, Zope 2.7.0, and FreeBSD 4.9 on a slightly slower machine. However, now Zope is crashing with a segmentation fault when I try to edit one of the largest Python scripts (19k) in my site. This is a script that I last edited on the old machine. It runs fine, displays fine in the management interface, but trying to save it causes Zope to crash. Searching online seems to indicate that I should have set a larger stack size for Python. I didn't install Python from the FreeBSD ports collection (for various reasons), but did it myself. Does the Python stack size sound like the problem? If it helps, gdb traceback gives me: (and I don't know what most of this means) #0 0x080729f3 in lookdict_string (mp=0x867e4f4, key=0x815b4e0, hash=435549560) at Objects/dictobject.c:316 #1 0x08073741 in PyDict_GetItem (op=0x867e4f4, key=0x815b4e0) at Objects/dictobject.c:498 #2 0x0805b3c0 in class_lookup (cp=0x868526c, name=0x815b4e0, pclass=0xbfaab088) at Objects/classobject.c:189 #3 0x0805b807 in instance_getattr2 (inst=0x904548c, name=0x815b4e0) at Objects/classobject.c:729 #4 0x08060c65 in instance_getattr1 (inst=0x904548c, name=0x815b4e0) at Objects/classobject.c:708 Any help is appreciated. Aaron
Searching online seems to indicate that I should have set a larger stack size for Python. I didn't install Python from the FreeBSD ports collection (for various reasons), but did it myself.
Does the Python stack size sound like the problem?
Absolutely! Zope+FreeBSD+segfault = stack size problems in 99,99% of cases :)
Yes, that's the problem. There's plenty of information on that. In my experience FreeBSD simply doesn't like Zope. Even though I tried all the workarounds, I expect a crash every now and then (every thirty or twenty days more or less). So I got used to rely on the control process to keep Zope running, because I just can't get rid of the OS. FreeBSD fans won't agree, for sure. So whether there's an ultimate success story on the issue, please share your top notch measures. (Not wanting to start a flame war here.) Ausum ----- Original Message ----- From: "AM" <maupin@pastrytech.com> To: <zope@zope.org> Sent: Tuesday, June 15, 2004 8:25 AM Subject: [Zope] Zope 2.7.0 crash on FreeBSD 5.2
Hello,
I've recently installed Python 2.3.4 and Zope 2.7.0 on FreeBSD 5.2 and moved my Data.fs over with no apparent problems (at first). Previously I was using Python 2.3.3, Zope 2.7.0, and FreeBSD 4.9 on a slightly slower machine.
However, now Zope is crashing with a segmentation fault when I try to edit one of the largest Python scripts (19k) in my site. This is a script that I last edited on the old machine. It runs fine, displays fine in the management interface, but trying to save it causes Zope to crash.
Searching online seems to indicate that I should have set a larger stack size for Python. I didn't install Python from the FreeBSD ports collection (for various reasons), but did it myself.
Does the Python stack size sound like the problem?
If it helps, gdb traceback gives me:
(and I don't know what most of this means)
#0 0x080729f3 in lookdict_string (mp=0x867e4f4, key=0x815b4e0, hash=435549560) at Objects/dictobject.c:316 #1 0x08073741 in PyDict_GetItem (op=0x867e4f4, key=0x815b4e0) at Objects/dictobject.c:498 #2 0x0805b3c0 in class_lookup (cp=0x868526c, name=0x815b4e0, pclass=0xbfaab088) at Objects/classobject.c:189 #3 0x0805b807 in instance_getattr2 (inst=0x904548c, name=0x815b4e0) at Objects/classobject.c:729 #4 0x08060c65 in instance_getattr1 (inst=0x904548c, name=0x815b4e0) at Objects/classobject.c:708
Any help is appreciated.
Aaron
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Ausum Studio <ausum_studio@hotmail.com> on 6/15/04 wrote:
Yes, that's the problem. There's plenty of information on that. In my experience FreeBSD simply doesn't like Zope. Even though I tried all the workarounds, I expect a crash every now and then (every thirty or twenty days more or less). So I got used to rely on the control process to keep Zope running, because I just can't get rid of the OS.
FreeBSD fans won't agree, for sure. So whether there's an ultimate success story on the issue, please share your top notch measures. (Not wanting to start a flame war here.)
we run hundreds of zopes on multiple freebsd boxen without OS-related issues, so this is pure FUD. zope and freebsd are good friends, just as long as the stacksize has been upped which is not hard to do. :) <--> george donnelly ~ http://www.zettai.net/ ~ "Quality Zope Hosting" Shared and Dedicated Zope Hosting ~ Zope Servers ~ Zope Websites Yahoo, AIM: zettainet ~ ICQ: 51907738 ~ Sales (USA): 1-866-967-3669
On Wednesday 16 June 2004 09:33 am, george donnelly wrote:
we run hundreds of zopes on multiple freebsd boxen without OS-related issues, so this is pure FUD. zope and freebsd are good friends, just as long as the stacksize has been upped which is not hard to do. :)
No it is not FUD. At least, not on a FreeBSD fakeroot jail system like I'm using at Imeme. Transferring new product code over from Linux to FreeBSD is a constant headache for me. Particular Zope features like ImageFile seem to be subject to serious failures on this system. I think it has something to do with limited access to file-handles, but I've not been able to localize the problem yet (I'm not so interested in that question, as in how to get my stuff to run on it with the minimum amount of fuss). But there are several things that have to be done differently on FreeBSD in order to work. And what's particularly annoying is that the work-arounds are often wasteful of memory. For example, I use small GIF images to report error messages in VarImage. This should happen rarely, so it would normally be desireable to simply load them from disk as needed. But while this works wonderfully on Linux, it chokes practically every time on FreeBSD. Now I'm not sure why. It might be that only the main thread can get file-handles. Or it may be that there are just not enough of them (I have actually seen Zope not be able to load all of the management icons when the server is heavily loaded). But for whatever reason, FreeBSD requires an expensive work-around, which is to pre-load all the images at class initialization time, so they hang around in memory. Alternatively, I can load these images into the ZODB, but that's not really all that attractive, unless it's something the administrator should have control over. In this case, it's not so bad, because these images are small, but if I had to include a bunch of fine print in them, I'd be in trouble. ;-) The main justification for using FreeBSD, as it was explained to me, was the fakeroot jail system. But I would like to point out that Debian Linux includes a fakeroot jail system package, at least in the Sarge (now testing) release: http://packages.debian.org/testing/admin/jailer I know it's probably less mature on Linux, but I'm certainly looking forward to someone offering this service on a Linux platform (BTW, the sacrifice of using FreeBSD has been well worth it, because Imeme provides good service for the cost, and I think the fakeroot jail is the reason they can do so). At one level, I feel it's good that I go through this particular headache -- if my products manage to run on both Linux and FreeBSD, there's a good chance I've flushed out additional bugs in my work. But I get tired of these "bugs" that shouldn't be bugs, because the system really ought to be able to cope with them (or to put it a different way, there exists a free-software system that does, and there are advantages to doing them the way I initially did, over the way I'm forced to do them to get FreeBSD compatibility). It's also possible that the fakeroot jails would have the same problem on Linux, in which case, I'm misidentifying the source of my headaches. But I don't think either justifies calling it FUD. There are real reasons to be wary of using FreeBSD, especially if you are developing on Linux. You definitely will see problems when you port your code. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
But I don't think either justifies calling it FUD. There are real reasons to be wary of using FreeBSD, especially if you are developing on Linux. You definitely will see problems when you port your code.
Cheers, Terry
I write all my code on a FreeBSD servers and have never had an issue with that code running on Linux (ZC only runs Linux in production). The only pain I have with Linux -> FreeBSD is people who write around things that are only found on Linux (for example buildouts that presume things like /etc/rc.d/init.d/functions or init scripts that presume the system has chkconfig or specific paths which are different on BSD systems if someone relies on RPMs) - otherwise, many large projects and many years of running FreeBSD tells me differently. I'm with George on this one, your problems are not FreeBSD unless you're not upping the stack size, in which case you'll be seeing seg faults in the log. Andrew
Terry Hancock <hancock@anansispaceworks.com> on 6/25/04 wrote:
At least, not on a FreeBSD fakeroot jail system like I'm using at Imeme. Transferring new product code over from Linux to FreeBSD is a constant headache for me.
well that is different from saying the zope does not like freebsd or zope is not stable on freebsd or zope is just not suited for freebsd, which is completely incorrect and which is indeed FUD.
Now I'm not sure why. It might be that only the main thread can get file-handles. Or it may be that there are just not enough of them (I have actually seen Zope not be able to load all of the management icons when the server is heavily loaded).
that sounds like its a result not of freebsd but of the configuration/limits you are working under. sorry to hear about your difficulties. <--> george donnelly ~ http://www.zettai.net/ ~ "Quality Zope Hosting" Shared and Dedicated Zope Hosting ~ Zope Servers ~ Zope Websites Yahoo, AIM: zettainet ~ ICQ: 51907738 ~ Sales (USA): 1-866-967-3669
FreeBSD fans won't agree, for sure. So whether there's an ultimate success story on the issue, please share your top notch measures. (Not wanting to start a flame war here.)
We have been running Zope on FreeBSD (4.x) for the past 4+ years and never had any real problems. Our largest instance averages around 6 req/sec and the ZODB is 2-3GB. Yes the stack size was an issue, but that was easily fixed. We also noted some threading issues when packing a DirectoryStorage database. I have worked arond them by compiling python against LinuxThreads. This was for python 2.1.3 and Zope 2.6, and some initial tests seem to suggest the newer pythons may not have the same issue. We occasionally see crashes, but nothing regular, possibly once a month or so. We deal with it by running multiple ZEO clients and pound in front. If one goes, then the other takes the load. We have lots and lots of custom code, and third party products, so I'm not really surprised by this. This is more useful for restarting Zope when updating products etc. We don't run FreeBSD 5.x yet, so I can't comment on that. I know that the threading is all different, whether this helps or harms python on SMP systems, I don't yet know. -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development and Consulting | Co-location | Hosting
Searching online seems to indicate that I should have set a larger stack size for Python. I didn't install Python from the FreeBSD ports collection (for various reasons), but did it myself.
Yes, it sounds like a stack size issue. Look at the Makefile for python in the FreeBSD ports collection and you will see the flag that it passes to configure for python to increase the stack size. You should be able to apply that when you compile your own version. -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development and Consulting | Co-location | Hosting
participants (7)
-
AM -
Andrew Sawyers -
Ausum Studio -
george donnelly -
Matt Hamilton -
Sergey Volobuev -
Terry Hancock