Skip Menu |

This queue is for tickets about the Math-Pari CPAN distribution.

Report information
The Basics
Id: 130787
Status: open
Priority: 0/
Queue: Math-Pari
People
Owner: Nobody in particular
Requestors: vbmoneymaker [...] gmail.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Wed Oct 23 03:46:19 2019 vbmoneymaker [...] gmail.com - Ticket created
Subject: Apache Segfault with Math-Pari-2.030518
Date: Wed, 23 Oct 2019 00:45:55 -0700
To: bug-Math-Pari [...] rt.cpan.org
From: Vb <vbmoneymaker [...] gmail.com>
Hi Mr. Zahkarevich. I'm sorry to bother you but I'm stuck on getting an Apache webserver (2.4.41) running due to a segfault occurring in Math-Pari: httpd[25688]: segfault at e ip 00007f229009654f sp 00007ffe675a65e0 error 4 in Pari.so[7f2290042000+313000] I've spent a couple of days trying to figure out the problem and haven't been able to do it. I've setup previous servers using Centos 6 with the same setup and while there were some hiccups along the way I was always able to get Math-Pari running. In this case, the server is Centos 6.10 running on a Proliant dl360 G5 server. I've compiled Apache 2.4.41 with mod_perl-2.0.11 and libapreq2-2.13 and have included Crypt-Random-1.52. I tried using the yum versions of these programs but got the segmentation error so I then downloaded Math-Pari from metacpan along with Crypt-Random and ran perl Makefile.PL, make and make install on them. I also tested Math-Pari and it passed. I also compiled pari-2.3.5 which was downloaded into the Math-Pari directory and installed it. Also, Apache is running as prefork - here is the output on that: Server MPM: Prefork -D APACHE_MPM_DIR="server/mpm/prefork" I've attached a text file with the backtrace on the Apache core dump. The key lines from that are set forth below. Also, I've tried using the older versions of Math-Pari and pari which worked on the Centos 6.4 server we have running with essentially the same setup but none of those worked. Any help you could give me to figure out the problem would be great as I have to use the perl module Crypt-Random in the setup, which in turn relies on Math-Pari. Thanks Vince *#0 moveoffstack_newer_than (sv=0x1c0316a8) at Pari.xs:1382* sv1 = 0x2 nextsv = <value optimized out> ret = <value optimized out> *#1 0x00007f22900966da in XS_Math__Pari_DESTROY (my_perl=<value optimized Show quoted text
out>, cv=<value optimized out>)*
at Pari.xs:4315 sv = 0x1c0316a8 ostack = 0x2 <Address 0x2 out of bounds> oldavma = 139786421803280 howmany = <value optimized out> rv = <value optimized out> sp = <value optimized out> ax = 1 mark = <value optimized out>

Message body is not shown because sender requested not to inline it.

  Wed Oct 23 04:48:16 2019 nospam-abuse [...] ilyaz.org - Correspondence added
CC: ;
Subject: Re: [rt.cpan.org #130787] Apache Segfault with Math-Pari-2.030518
Date: Wed, 23 Oct 2019 01:40:44 -0700
To: Vb via RT <bug-Math-Pari [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Wed, Oct 23, 2019 at 03:46:20AM -0400, Vb via RT wrote: Show quoted text
> > *#0 moveoffstack_newer_than (sv=0x1c0316a8) at Pari.xs:1382* > sv1 = 0x2 > nextsv = <value optimized out> > ret = <value optimized out> > *#1 0x00007f22900966da in XS_Math__Pari_DESTROY (my_perl=<value optimized
> out>, cv=<value optimized out>)*
> at Pari.xs:4315 > sv = 0x1c0316a8 > ostack = 0x2 <Address 0x2 out of bounds> > oldavma = 139786421803280 > howmany = <value optimized out> > rv = <value optimized out> > sp = <value optimized out> > ax = 1 > mark = <value optimized out> >
I won’t be able to help with the Apache side, but do you have an idea which Math::Pari code has been running before this time? By default, Math::Pari should have been compiled with the -DDEBUG_PARI. Then one can do Math::Pari::PARI_DEBUG_set(1); and get a bit more info about our dirty manipulations with the PARI stack. All I can see is that the fault happened during the global destruction, when one of PARI object was left on the PARI stack. (Which, I think, is normal.) Do not know whether this may help you… Yours, Ilya
  Wed Oct 23 04:48:16 2019 The RT System itself - Status changed from 'new' to 'open'
  Wed Oct 23 06:11:47 2019 vbmoneymaker [...] gmail.com - Correspondence added
Subject: Re: [rt.cpan.org #130787] Apache Segfault with Math-Pari-2.030518
Date: Wed, 23 Oct 2019 03:11:15 -0700
To: bug-Math-Pari [...] rt.cpan.org
From: Vb <vbmoneymaker [...] gmail.com>
Hi Ilya, I really appreciate you getting back to me so quick. I feel like an idiot on this. I thought for sure apache had been compiled with the prefork MPM because that is supposed to be the default for Unix installs and when I ran httpd -V | grep MPM it showed up with the "Server MPM: Prefork" response I sent you. But after I emailed you I ran the httpd -l command just to be sure and it showed that the event.c module had been compiled in instead of the prefork.c module. So when I recompiled Apache with the --with-mpm=prefork option and restarted Apache, everything worked as it should. Again, really sorry for bothering you on this and I also appreciate how quickly you got back to me. Thanks Vince On Wed, Oct 23, 2019 at 1:48 AM Ilya Zakharevich via RT < bug-Math-Pari@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=130787 > > > On Wed, Oct 23, 2019 at 03:46:20AM -0400, Vb via RT wrote:
> > > > *#0 moveoffstack_newer_than (sv=0x1c0316a8) at Pari.xs:1382* > > sv1 = 0x2 > > nextsv = <value optimized out> > > ret = <value optimized out> > > *#1 0x00007f22900966da in XS_Math__Pari_DESTROY (my_perl=<value
> optimized
> > out>, cv=<value optimized out>)*
> > at Pari.xs:4315 > > sv = 0x1c0316a8 > > ostack = 0x2 <Address 0x2 out of bounds> > > oldavma = 139786421803280 > > howmany = <value optimized out> > > rv = <value optimized out> > > sp = <value optimized out> > > ax = 1 > > mark = <value optimized out> > >
> > I won’t be able to help with the Apache side, but do you have an idea > which Math::Pari code has been running before this time? > > By default, Math::Pari should have been compiled with the > -DDEBUG_PARI. Then one can do > Math::Pari::PARI_DEBUG_set(1); > and get a bit more info about our dirty manipulations with the PARI > stack. > > All I can see is that the fault happened during the global > destruction, when one of PARI object was left on the PARI stack. > (Which, I think, is normal.) Do not know whether this may help you… > > Yours, > Ilya > >