Restricted Compiler issues on FreeBSD? (Core Dumps...waaa!)
For a while now, Tracker has been core dumping on my with Zope 2.5.1 with both Python 2.1.2 and 2.1.3 on FreeBSD 4.5 (Intel). The culprit seems to be expressions that are heavy on parenthesis. For example, the following works: <!--#let val="(init or (type == 'simple' and (_['sequence-key'] not in ['requester', 'supporter', 'priority', 'stage']) )) and _['sequence-item']"--> But it core dumps when changed to: <!--#let val="((init or (type == 'simple' and (_['sequence-key'] not in ['requester', 'supporter', 'priority', 'stage']) )) and _['sequence-item'])"--> Don't ask me what this expression does - I just kept whittling at it until the crashes stopped. Then I went and found quite a few others. I made a lot of fixes by turning complex expressions into many smaller ones inside a single 'let' tag. Does anyone know other possible fixes for this issue? Is there some Python stack size setting I can set at compile time? I have some other code that has not survived the move to Zope 2.5.x/Python 2.1.x/FreeBSD. FWIW, the Python 2.1.2 used was from the BSD Ports, while the 2.1.3 was compiled by hand. -- Jeffrey P Shell www.cuemedia.com
have you read about the python crash-bug stemming from tiny thread stack sizes on freebsd and applied the patch? the mailing list archives should tell you what to do. jens On Tuesday, July 16, 2002, at 09:43 , Jeffrey P Shell wrote:
For a while now, Tracker has been core dumping on my with Zope 2.5.1 with both Python 2.1.2 and 2.1.3 on FreeBSD 4.5 (Intel). The culprit seems to be expressions that are heavy on parenthesis. For example, the following works:
<!--#let val="(init or (type == 'simple' and (_['sequence-key'] not in ['requester', 'supporter', 'priority', 'stage']) )) and _['sequence-item']"-->
But it core dumps when changed to:
<!--#let val="((init or (type == 'simple' and (_['sequence-key'] not in ['requester', 'supporter', 'priority', 'stage']) )) and _['sequence-item'])"-->
Don't ask me what this expression does - I just kept whittling at it until the crashes stopped. Then I went and found quite a few others. I made a lot of fixes by turning complex expressions into many smaller ones inside a single 'let' tag.
Does anyone know other possible fixes for this issue? Is there some Python stack size setting I can set at compile time? I have some other code that has not survived the move to Zope 2.5.x/Python 2.1.x/FreeBSD.
FWIW, the Python 2.1.2 used was from the BSD Ports, while the 2.1.3 was compiled by hand.
-- Jeffrey P Shell www.cuemedia.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Jens Vagelpohl writes:
have you read about the python crash-bug stemming from tiny thread stack sizes on freebsd and applied the patch? the mailing list archives should tell you what to do.
Ahh, thanks! I think I found the right patch and all. Won't get to find out if it all works until tomorrow. (After the keynote of course ;) Hopefully this nails the issue. It's been beating me up for a while now (primarily with older code, strangely enough). -- JPS
jeffrey wrote:
Jens Vagelpohl writes:
have you read about the python crash-bug stemming from tiny thread stack sizes on freebsd and applied the patch? the mailing list archives should tell you what to do.
Ahh, thanks! I think I found the right patch and all. Won't get to find out if it all works until tomorrow. (After the keynote of course ;) Hopefully this nails the issue. It's been beating me up for a while now (primarily with older code, strangely enough).
Jeffrey, Make sure you recompile your python scripts too (update to Zope 2.4.4 or Zope 2.5.1) as the older restricted python compiler generated bad constructs when dealing with large compound static constructs (ie lists of lists etc). Pythons prior to 2.1.3 lacked checks to assert that the data structures were properly generated, and would go off the deep end once they hit them. Python 2.1.3 will recognize bad structures and stop (albeit with messages that are cryptic to someone who isn't aware of the potential pitfalls). I dont remember off the top of my head what the magic "recompile all" url is, but it's there, and it should show up in the debug log when you restart and it notices that the magic number on python scripts has changed. -- Matt Kromer Zope Corporation http://www.zope.com/
participants (4)
-
jeffrey -
Jeffrey P Shell
-
Jens Vagelpohl -
Matthew T. Kromer