Thanks. The fix hasn't been integrated into the 5.24 maint branch so
any data we can have about it being battle tested is valuable.
Dominic.
On Thu, Jul 02, 2020 at 05:04:10PM -0700, Dean Hamstead wrote:
> We have been running it in prod since before the ticket was raised in
> debian. We were hop
On Wed, Jul 01, 2020 at 05:07:33PM -0700, Dean Hamstead wrote:
> My preference would be to apply the patch as its a genuine bug fix from
> upstream.
Hi Dean
Thanks for the reply. We do just have a chance to get it into the final
stretch point release and we do have other changes queued for perl n
My preference would be to apply the patch as its a genuine bug fix from
upstream.
On Wed, Jun 06, 2018 at 01:22:26PM +1000, Dean Hamstead wrote:
> Rolling it in to the official release would be much appreciated as it
> will spare us maintaining our own patched version, plus might help a
> few lonely travelers who are stumped on a segfault.
I'm sorry that we weren't able to get
Rolling it in to the official release would be much appreciated as it
will spare us maintaining our own patched version, plus might help a few
lonely travelers who are stumped on a segfault.
On Tue, Jun 05, 2018 at 01:19:13PM +1000, Tony Cook wrote:
> On Mon, Jun 04, 2018 at 09:31:06PM +0100, Dominic Hargreaves wrote:
> > Thanks for the detailed analysis both! Given that the fix is accidental,
> > and not in a released version of perl yet, I'm not sure whether this
> > belongs in a sta
On Mon, Jun 04, 2018 at 09:31:06PM +0100, Dominic Hargreaves wrote:
> Thanks for the detailed analysis both! Given that the fix is accidental,
> and not in a released version of perl yet, I'm not sure whether this
> belongs in a stable update. That said, maybe there is no more correct
> place for a
On Mon, Jun 04, 2018 at 03:08:19PM +1000, Tony Cook wrote:
> The underlying cause appears to be that libm is referencing
> _LIB_VERSION in libperl.
>
> I suspect the Oracle client libraries have dlopen()ed a library that
> depends on libm, and that isn't dlclosed() when mod_perl unloads
> DBD::Ora
The underlying cause appears to be that libm is referencing
_LIB_VERSION in libperl.
I suspect the Oracle client libraries have dlopen()ed a library that
depends on libm, and that isn't dlclosed() when mod_perl unloads
DBD::Oracle.
So the process that leads to the crash:
1) Apache starts it conf
9 matches
Mail list logo