Python Coredump on FreeBSD

[Harald Schneider]

With the patch applied it runs longer, but then dies with

python in realloc(): warning: modified (chunk-) pointer
Segmentation fault (core dumped)

Think I'll have to move away from threading on FreeBSD - It's definately not
stable.

-- Harald



"Harald Schneider" <h_schneider at marketmix.com> schrieb im Newsbeitrag
news:b9qafe$jid$05$1 at news.t-online.com...
> Pattern and strings can grow very large. That means pattern something like
>
> "Unknown local
> part|(user|mailbox|account|recipient|Addressee).*?(unknown|invalid|not
> found|not here)|(no such|doesn't
> have|invalid|unknown).*?(account|user|mailbox|recipient|addressee)"
>
> for the pattern and 5 - 500 KB for the strings being searched.
>
> Indeed there is an issue with the stacksize on FreeBSD wich also forces
Zope
> to crash. I found a patch fpr Python 2.1.3, which
> should fix this issue:
> http://zwiki.org/PatchPython213
>
> At the moment, I rebuilt Python from source with that patch applied. If
this
> doesn't solve my problem, I'll try to mimmize stack usage by unsing
smaller
> regex patterns and search strings ... oh boy ... :-)
>
> I'll keep you posted - thanks!
>
> --Harald
>
> "Master of the Unixverse" <ah at abraxas.devsoft.com> schrieb im Newsbeitrag
> news:slrnbc009f.aa.ah at abraxas.devsoft.com...
> > In article <ox2cnT5extyQQCKjXTWcpg at speakeasy.net>, A.M. Kuchling wrote:
> > > On Mon, 12 May 2003 16:20:08 +0200,
> > > Harald Schneider <h_schneider at marketmix.com> wrote:
> > >> When I call
> > >> re.compile(.......).search(.....)
> > >> in sequence a few times, then the regular expression module re causes
> this
> > >> coredump. It's implementation must differ from other platforms. It
> looks
> > >
> > > What is the pattern being compiled, and how large is the string being
> > > searched?  There are patterns that consume a lot of C stack space
while
> > > searching.  There's a fixed recursion limit that's intended to prevent
> core
> > > dumps, and it's possible the recursion limit is set incorrectly for
> FreeBSD.
> >
> > The application is multithreaded and there is indeed a "problem" with
> > threads on FreeBSD vs. Linux here:  the default stacksize that a thread
> > gets is different bewteen Linux and FreeBSD.  Linux threads have more
> > default stacksize.  No idea about Windows.  So this may very well be
> > the reason.
> >
> > Anton Hartl, ah AT muc DOT de
>
>