Scrip doesn't work

Mohamed_Ali_Bouirman · June 6, 2006, 6:53pm

Hi all,

I have some troubles running scrips with a new RT 3.4.5 installation. I’ve
tried many samples found in the RT wiki but the result is always the same:
the scrip action is not triggered.

here is an example of scrip tested:
http://wiki.bestpractical.com/index.cgi?ResolveTicket

Best Regards

Nazark_Kulynych · June 7, 2006, 8:20pm

I have recently installed RT 3.4.5, when I try to add users I get the
following message in my apache error_log.

[Wed Jun 07 23:17:36 2006] [notice] child pid 18164 exit signal
Segmentation fault (11)
[Wed Jun 7 20:17:36 2006] [crit]: Transaction not committed. Usually
indicates a software fault.Data loss may have occurred
(/www/apps/rt-3.4.5/lib/RT/Interface/Web/Handler.pm:205)

Any idea?

thanks
Nazar

Nazark_Kulynych · June 7, 2006, 9:12pm

I have recently installed RT 3.4.5, when I try to add users I get the
following message in my apache error_log.

[Wed Jun 07 23:17:36 2006] [notice] child pid 18164 exit signal
Segmentation fault (11)
[Wed Jun 7 20:17:36 2006] [crit]: Transaction not committed. Usually
indicates a software fault.Data loss may have occurred
(/www/apps/rt-3.4.5/lib/RT/Interface/Web/Handler.pm:205)

Any idea?

thanks
Nazar

Jesse_Vincent · June 9, 2006, 3:39pm

this usually indicates a bad dso mod_perl 1.0 build
Best,
Jesse
This message was sent from my Treo. Please accept my apologies for its brevity and for any typos.-----Original Message-----
From: Nazar Kulynych nazark@auska.com
Date: Wednesday, Jun 7, 2006 5:12 pm
Subject: [rt-users] Segmentation Fault

I have recently installed RT 3.4.5, when I try to add users I get the following message in my apache error_log.

[Wed Jun 07 23:17:36 2006] [notice] child pid 18164 exit signal Segmentation fault (11)
[Wed Jun 7 20:17:36 2006] [crit]: Transaction not committed. Usually indicates a software fault.Data loss may have occurred (/www/apps/rt-3.4.5/lib/RT/Interface/Web/Handler.pm:205)

Any idea?

thanks
Nazar

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media. Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html

Nazark_Kulynych · June 10, 2006, 1:38am

I have this $ENV

apache-2.0.58
rt-3.4.5
perl-5.8.5
mod_perl-2.0.2

apache and mod_perl compiled statically.

Thanks
Nazar

this usually indicates a bad dso mod_perl 1.0 build
Best,
Jesse
– This message was sent from my Treo. Please accept my apologies for
its brevity and for any typos. -----Original Message----- From: Nazar
Kulynych nazark@auska.com Date: Wednesday, Jun 7, 2006 5:12 pm
3.4.5, when I try to add users I get the following message in my apache
error_log. [Wed Jun 07 23:17:36 2006] [notice] child pid 18164 exit
signal Segmentation fault (11) [Wed Jun 7 20:17:36 2006] [crit]:
Transaction not committed. Usually indicates a software fault.Data loss
may have occurred
(/www/apps/rt-3.4.5/lib/RT/Interface/Web/Handler.pm:205) Any idea?
thanks Nazar _______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com Commercial support:
sales@bestpractical.com Discover RT’s hidden secrets with RT Essentials
from O’Reilly Media. Buy a copy at http://rtbook.bestpractical.com We’re
hiring! Come hack Perl for Best Practical:
http://bestpractical.com/about/jobs.html

George_Beitis · January 16, 2009, 10:00am

Hey guys,
i was running RT fine for the last couple of days, and as i was about to
create a ticket everything died. Apache error logs
[notice] child pid 7384 exit signal Segmentation fault (11)

I am running :
Apache/2.2.9 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0 configured

with the latest versions of RT, RTIR, and RTFQ .

As i said everything was fine, no updates or anything

Any ideas on how to fix this? anyone with similar issues?

George

George_Beitis · January 16, 2009, 11:56am

Update:
After spending using strace on apache i keep seeing the following:

.
.
.
11845 stat64(“/usr/local/share/perl/5.10.0/auto/DBI/DESTROY.al”, 0xbff99e80)
= -1 ENOENT (No such file or directory)
11845 stat64(“/usr/lib/perl5/auto/DBI/DESTROY.al”, 0xbff99e80) = -1 ENOENT
(No such file or directory)
11845 stat64(“/usr/share/perl5/auto/DBI/DESTROY.al”, 0xbff99e80) = -1 ENOENT
(No such file or directory)
11845 stat64(“/usr/lib/perl/5.10/auto/DBI/DESTROY.al”, 0xbff99e80) = -1
ENOENT (No such file or directory)
11845 stat64(“/usr/share/perl/5.10/auto/DBI/DESTROY.al”, 0xbff99e80) = -1
ENOENT (No such file or directory)
11845 stat64(“/usr/local/lib/site_perl/auto/DBI/DESTROY.al”, 0xbff99e80) =
-1 ENOENT (No such file or directory)
11845 stat64(“./auto/DBI/DESTROY.al”, 0xbff99e80) = -1 ENOENT (No such file
or directory)
11845 stat64(“/etc/apache2/auto/DBI/DESTROY.al”, 0xbff99e80) = -1 ENOENT (No
such file or directory)
11845 munmap(0xb73c1000, 20664) = 0
11845 munmap(0xb738d000, 45264) = 0
11845 munmap(0xb73b9000, 28980) = 0
11845 munmap(0xb7385000, 28936) = 0

and it seems that it can not locate DESTROY.al which i think might be the
reason of the segemntation faults i keep getting from apache

Any ideas??

GeorgeOn Fri, Jan 16, 2009 at 12:00 PM, George Beitis < george.beitis@googlemail.com> wrote:

Hey guys,
i was running RT fine for the last couple of days, and as i was about to
create a ticket everything died. Apache error logs
[notice] child pid 7384 exit signal Segmentation fault (11)

I am running :
Apache/2.2.9 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0 configured

with the latest versions of RT, RTIR, and RTFQ .

As i said everything was fine, no updates or anything

Any ideas on how to fix this? anyone with similar issues?

George

Ruslan_Zakirov · January 16, 2009, 12:43pm

if you’re on mysql and DBD::mysql 4.00x then you need 4.010 or never
where at least one seg fault has been fixed.On Fri, Jan 16, 2009 at 2:56 PM, George Beitis george.beitis@googlemail.com wrote:

Update:
After spending using strace on apache i keep seeing the following:

.
.
.
11845 stat64(“/usr/local/share/perl/5.10.0/auto/DBI/DESTROY.al”, 0xbff99e80)
= -1 ENOENT (No such file or directory)
11845 stat64(“/usr/lib/perl5/auto/DBI/DESTROY.al”, 0xbff99e80) = -1 ENOENT
(No such file or directory)
11845 stat64(“/usr/share/perl5/auto/DBI/DESTROY.al”, 0xbff99e80) = -1 ENOENT
(No such file or directory)
11845 stat64(“/usr/lib/perl/5.10/auto/DBI/DESTROY.al”, 0xbff99e80) = -1
ENOENT (No such file or directory)
11845 stat64(“/usr/share/perl/5.10/auto/DBI/DESTROY.al”, 0xbff99e80) = -1
ENOENT (No such file or directory)
11845 stat64(“/usr/local/lib/site_perl/auto/DBI/DESTROY.al”, 0xbff99e80) =
-1 ENOENT (No such file or directory)
11845 stat64(“./auto/DBI/DESTROY.al”, 0xbff99e80) = -1 ENOENT (No such file
or directory)
11845 stat64(“/etc/apache2/auto/DBI/DESTROY.al”, 0xbff99e80) = -1 ENOENT (No
such file or directory)
11845 munmap(0xb73c1000, 20664) = 0
11845 munmap(0xb738d000, 45264) = 0
11845 munmap(0xb73b9000, 28980) = 0
11845 munmap(0xb7385000, 28936) = 0

and it seems that it can not locate DESTROY.al which i think might be the
reason of the segemntation faults i keep getting from apache

Any ideas??

George

On Fri, Jan 16, 2009 at 12:00 PM, George Beitis george.beitis@googlemail.com wrote:

Hey guys,
i was running RT fine for the last couple of days, and as i was about to
create a ticket everything died. Apache error logs
[notice] child pid 7384 exit signal Segmentation fault (11)

I am running :
Apache/2.2.9 (Ubuntu) mod_perl/2.0.4 Perl/v5.10.0 configured

with the latest versions of RT, RTIR, and RTFQ .

As i said everything was fine, no updates or anything

Any ideas on how to fix this? anyone with similar issues?

George

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Paul_Franson · January 28, 2009, 1:37am

I have a problem that I think may be database specific, but I’m lost in how to troubleshoot further.

I have a working 3.6.3 system that I want to port to a test machine running 3.8.x.

I took a minimal Fedora 10 install and installed RT3 from “yum”. I then upgraded the DBD::mysql using CPAN to 4.010

I mysqldump’ed the 3.6.3 database (using -default-character-set=binary), sftp’ed the dump over to the new box, and pumped it into the new mysql database there. I then ran rt-setup-database -action upgrade from 3.6.3 to 3.8.1 (which is what yum installed for me).

After customizing the RT_SiteConfig.pm file, I can log in and see my cases on my home screen, but as soon as I attempt to either go into a case, or hit anything else on the screen (tickets, configuration, …), I get hit with a segmentation fault.

As I said - I’m fairly sure that this is a database issue on my end (starting out with a blank database and populating it with several cases, I don’t see any problems - just when I add my 3-year old, 1.1GB database). If anyone has any suggestions for further troubleshooting, I’d love to hear them!!

I ran GDB and backtraced from the point of the seg fault, and this is what I got:

(hitting “Configure” in the menu):

Program received signal SIGSEGV, Segmentation fault.
memcpy () at …/sysdeps/i386/i686/memcpy.S:75
75 rep
Current language: auto; currently asm
(gdb) bt
#0 memcpy () at …/sysdeps/i386/i686/memcpy.S:75
#1 0xba9dad1c in ?? ()
#2 0x00de43c2 in retrieve_hash (my_perl=0xbb1b3a80, cxt=0x426f16f8, cname=0x0) at /usr/include/bits/string3.h:52
#3 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:5967
#4 0x00de22a0 in retrieve_ref (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:4477
#5 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:5967
#6 0x00de48ad in retrieve_array (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:5159
#7 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:5967
#8 0x00de22a0 in retrieve_ref (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:4477
#9 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:5967
#10 0x00de42d6 in retrieve_hash (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:5214
#11 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0) at Storable.xs:5967
#12 0x00de0742 in do_retrieve (my_perl=0xbb1b3a80, f=0x0, in=0xbb16512c, optype=2) at Storable.xs:6148
#13 0x00de18b4 in mretrieve () at Storable.xs:6264
#14 XS_Storable_mretrieve (my_perl=0xbb1b3a80, cv=0xba9d6b0c) at Storable.xs:6460
#15 0x00af66f9 in Perl_pp_entersub (my_perl=0xbb1b3a80) at pp_hot.c:2847
#16 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931
#17 0x00b65d0f in S_docatch (my_perl=0xbb1b3a80, o=) at pp_ctl.c:2679
#18 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931
#19 0x00aef64d in Perl_call_sv (my_perl=0xbb1b3a80, sv=0xbc191934, flags=) at perl.c:2631
#20 0x00b93dc8 in Perl_pp_tie (my_perl=0xbb1b3a80) at pp_sys.c:850
#21 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931
#22 0x00b65d0f in S_docatch (my_perl=0xbb1b3a80, o=) at pp_ctl.c:2679
#23 0x00b68e4d in Perl_pp_entereval (my_perl=0xbb1b3a80) at pp_ctl.c:3617
#24 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931
#25 0x00aef64d in Perl_call_sv (my_perl=0xbb1b3a80, sv=0xbc17fb64, flags=) at perl.c:2631
#26 0x00b93dc8 in Perl_pp_tie (my_perl=0xbb1b3a80) at pp_sys.c:850
#27 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931
#28 0x00aefa58 in Perl_call_sv (my_perl=0xbb1b3a80, sv=0xbac33804, flags=4) at perl.c:2646
#29 0x009e6da4 in modperl_callback () from /etc/httpd/modules/mod_perl.so
#30 0x009e7b3c in modperl_callback_run_handlers () from /etc/httpd/modules/mod_perl.so
#31 0x009e856a in modperl_callback_per_dir () from /etc/httpd/modules/mod_perl.so
#32 0x009df5ff in ?? () from /etc/httpd/modules/mod_perl.so
#33 0x009df7c5 in modperl_response_handler_cgi () from /etc/httpd/modules/mod_perl.so
#34 0xb7ef2b7d in ap_run_handler (r=0xbae277d8) at /usr/src/debug/httpd-2.2.10/server/config.c:158
#35 0xb7ef66cf in ap_invoke_handler (r=0xbae277d8) at /usr/src/debug/httpd-2.2.10/server/config.c:372
#36 0xb7f02ea1 in ap_process_request (r=0xbae277d8) at /usr/src/debug/httpd-2.2.10/modules/http/http_request.c:258
#37 0xb7effab8 in ap_process_http_connection (c=0xbae1b940) at /usr/src/debug/httpd-2.2.10/modules/http/http_core.c:190
#38 0xb7efae9d in ap_run_process_connection (c=0xbae1b940) at /usr/src/debug/httpd-2.2.10/server/connection.c:43
#39 0xb7f082d1 in child_main (child_num_arg=)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:650
#40 0xb7f08599 in make_child (s=, slot=0)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:690
#41 0xb7f092f0 in ap_mpm_run (_pconf=0xb9cfc5c0, plog=0xb9d2a678, s=0xb9cfe4b8)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:966
#42 0xb7edd7c9 in main (argc=-1177573960, argv=0xbfc18cb4) at /usr/src/debug/httpd-2.2.10/server/main.c:740

(when selecting a case):
Program received signal SIGSEGV, Segmentation fault.
sYSMALLOc () at malloc.c:3358
3358 set_head(remainder, remainder_size | PREV_INUSE);
(gdb) bt
#0 sYSMALLOc () at malloc.c:3358
#1 _int_malloc (av=0x54f140, bytes=1918986097) at malloc.c:4580
#2 0x00450d5f in _int_realloc (av=0x54f140, oldmem=0xbad35f90, bytes=1918986098) at malloc.c:5035
#3 0x00451c86 in __libc_realloc (oldmem=0xbad35f90, bytes=1918986098) at malloc.c:3708
#4 0x00acb759 in Perl_safesysrealloc (where=, size=1918986098) at util.c:178
#5 0x00de4362 in retrieve_hash (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:5226
#6 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:5967
#7 0x00de22a0 in retrieve_ref (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:4477
#8 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:5967
#9 0x00de48ad in retrieve_array (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:5159
#10 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:5967
#11 0x00de22a0 in retrieve_ref (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:4477
#12 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:5967
#13 0x00de42d6 in retrieve_hash (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:5214
#14 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0) at Storable.xs:5967
#15 0x00de0742 in do_retrieve (my_perl=0xb9c64a28, f=0x0, in=0xbad32f1c, optype=2) at Storable.xs:6148
#16 0x00de18b4 in mretrieve () at Storable.xs:6264
#17 XS_Storable_mretrieve (my_perl=0xb9c64a28, cv=0xb94893a4) at Storable.xs:6460
#18 0x00af66f9 in Perl_pp_entersub (my_perl=0xb9c64a28) at pp_hot.c:2847
#19 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931
#20 0x00b65d0f in S_docatch (my_perl=0xb9c64a28, o=) at pp_ctl.c:2679
#21 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931
#22 0x00aef64d in Perl_call_sv (my_perl=0xb9c64a28, sv=0xbac4266c, flags=) at perl.c:2631
#23 0x00b93dc8 in Perl_pp_tie (my_perl=0xb9c64a28) at pp_sys.c:850
#24 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931
#25 0x00b65d0f in S_docatch (my_perl=0xb9c64a28, o=) at pp_ctl.c:2679
#26 0x00b68e4d in Perl_pp_entereval (my_perl=0xb9c64a28) at pp_ctl.c:3617
#27 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931
#28 0x00aef64d in Perl_call_sv (my_perl=0xb9c64a28, sv=0xbac30874, flags=) at perl.c:2631
#29 0x00b93dc8 in Perl_pp_tie (my_perl=0xb9c64a28) at pp_sys.c:850
#30 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931
#31 0x00aefa58 in Perl_call_sv (my_perl=0xb9c64a28, sv=0xb96e6084, flags=4) at perl.c:2646
#32 0x009e6da4 in modperl_callback () from /etc/httpd/modules/mod_perl.so
#33 0x009e7b3c in modperl_callback_run_handlers () from /etc/httpd/modules/mod_perl.so
#34 0x009e856a in modperl_callback_per_dir () from /etc/httpd/modules/mod_perl.so
#35 0x009df5ff in ?? () from /etc/httpd/modules/mod_perl.so
#36 0x009df7c5 in modperl_response_handler_cgi () from /etc/httpd/modules/mod_perl.so
#37 0xb7f03b7d in ap_run_handler (r=0xb98ddfe0) at /usr/src/debug/httpd-2.2.10/server/config.c:158
#38 0xb7f076cf in ap_invoke_handler (r=0xb98ddfe0) at /usr/src/debug/httpd-2.2.10/server/config.c:372
#39 0xb7f13ea1 in ap_process_request (r=0xb98ddfe0) at /usr/src/debug/httpd-2.2.10/modules/http/http_request.c:258
#40 0xb7f10ab8 in ap_process_http_connection (c=0xb98ce138) at /usr/src/debug/httpd-2.2.10/modules/http/http_core.c:190
#41 0xb7f0be9d in ap_run_process_connection (c=0xb98ce138) at /usr/src/debug/httpd-2.2.10/server/connection.c:43
#42 0xb7f192d1 in child_main (child_num_arg=)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:650
#43 0xb7f19599 in make_child (s=, slot=0)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:690
#44 0xb7f1a2f0 in ap_mpm_run (_pconf=0xb87ad5c0, plog=0xb87db678, s=0xb87af4b8)
—Type to continue, or q to quit—
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:966
#45 0xb7eee7c9 in main (argc=-1199917640, argv=0xbfd2a5c4) at /usr/src/debug/httpd-2.2.10/server/main.c:740

I’ve also tried building a 3.8.2 from scratch using Debian-Lenny and got the same overall effect (didn’t get the GDB traces from that system, but the symptoms are the same).

Paul Franson

Ruslan_Zakirov · January 28, 2009, 1:56am

I think you have to read UPGRADING.mysql instructions. In mysql
console run “show create table sessions;” and if it has LONGTEXT then
you definitelly must read that file.On Wed, Jan 28, 2009 at 4:37 AM, Paul Franson pfranson@monogrambio.com wrote:

I have a problem that I think may be database specific, but I’m lost in how
to troubleshoot further.

I have a working 3.6.3 system that I want to port to a test machine running
3.8.x.

I took a minimal Fedora 10 install and installed RT3 from “yum”. I then
upgraded the DBD::mysql using CPAN to 4.010

I mysqldump’ed the 3.6.3 database (using –default-character-set=binary),
sftp’ed the dump over to the new box, and pumped it into the new mysql
database there. I then ran rt-setup-database –action upgrade from 3.6.3 to
3.8.1 (which is what yum installed for me).

After customizing the RT_SiteConfig.pm file, I can log in and see my cases
on my home screen, but as soon as I attempt to either go into a case, or hit
anything else on the screen (tickets, configuration, …), I get hit with a
segmentation fault.

As I said – I’m fairly sure that this is a database issue on my end
(starting out with a blank database and populating it with several cases, I
don’t see any problems – just when I add my 3-year old, 1.1GB database). If
anyone has any suggestions for further troubleshooting, I’d love to hear
them!!

I ran GDB and backtraced from the point of the seg fault, and this is what I
got:

(hitting “Configure” in the menu):

Program received signal SIGSEGV, Segmentation fault.

memcpy () at …/sysdeps/i386/i686/memcpy.S:75

75 rep

Current language: auto; currently asm

(gdb) bt

#0 memcpy () at …/sysdeps/i386/i686/memcpy.S:75

#1 0xba9dad1c in ?? ()

#2 0x00de43c2 in retrieve_hash (my_perl=0xbb1b3a80, cxt=0x426f16f8,
cname=0x0) at /usr/include/bits/string3.h:52

#3 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0)
at Storable.xs:5967

#4 0x00de22a0 in retrieve_ref (my_perl=0xbb1b3a80, cxt=0xba9dad1c,
cname=0x0) at Storable.xs:4477

#5 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0)
at Storable.xs:5967

#6 0x00de48ad in retrieve_array (my_perl=0xbb1b3a80, cxt=0xba9dad1c,
cname=0x0) at Storable.xs:5159

#7 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0)
at Storable.xs:5967

#8 0x00de22a0 in retrieve_ref (my_perl=0xbb1b3a80, cxt=0xba9dad1c,
cname=0x0) at Storable.xs:4477

#9 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0)
at Storable.xs:5967

#10 0x00de42d6 in retrieve_hash (my_perl=0xbb1b3a80, cxt=0xba9dad1c,
cname=0x0) at Storable.xs:5214

#11 0x00ddfafd in retrieve (my_perl=0xbb1b3a80, cxt=0xba9dad1c, cname=0x0)
at Storable.xs:5967

#12 0x00de0742 in do_retrieve (my_perl=0xbb1b3a80, f=0x0, in=0xbb16512c,
optype=2) at Storable.xs:6148

#13 0x00de18b4 in mretrieve () at Storable.xs:6264

#14 XS_Storable_mretrieve (my_perl=0xbb1b3a80, cv=0xba9d6b0c) at
Storable.xs:6460

#15 0x00af66f9 in Perl_pp_entersub (my_perl=0xbb1b3a80) at pp_hot.c:2847

#16 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931

#17 0x00b65d0f in S_docatch (my_perl=0xbb1b3a80, o=) at
pp_ctl.c:2679

#18 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931

#19 0x00aef64d in Perl_call_sv (my_perl=0xbb1b3a80, sv=0xbc191934,
flags=) at perl.c:2631

#20 0x00b93dc8 in Perl_pp_tie (my_perl=0xbb1b3a80) at pp_sys.c:850

#21 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931

#22 0x00b65d0f in S_docatch (my_perl=0xbb1b3a80, o=) at
pp_ctl.c:2679

#23 0x00b68e4d in Perl_pp_entereval (my_perl=0xbb1b3a80) at pp_ctl.c:3617

#24 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931

#25 0x00aef64d in Perl_call_sv (my_perl=0xbb1b3a80, sv=0xbc17fb64,
flags=) at perl.c:2631

#26 0x00b93dc8 in Perl_pp_tie (my_perl=0xbb1b3a80) at pp_sys.c:850

#27 0x00ab7f03 in Perl_runops_debug (my_perl=0xbb1b3a80) at dump.c:1931

#28 0x00aefa58 in Perl_call_sv (my_perl=0xbb1b3a80, sv=0xbac33804, flags=4)
at perl.c:2646

#29 0x009e6da4 in modperl_callback () from /etc/httpd/modules/mod_perl.so

#30 0x009e7b3c in modperl_callback_run_handlers () from
/etc/httpd/modules/mod_perl.so

#31 0x009e856a in modperl_callback_per_dir () from
/etc/httpd/modules/mod_perl.so

#32 0x009df5ff in ?? () from /etc/httpd/modules/mod_perl.so

#33 0x009df7c5 in modperl_response_handler_cgi () from
/etc/httpd/modules/mod_perl.so

#34 0xb7ef2b7d in ap_run_handler (r=0xbae277d8) at
/usr/src/debug/httpd-2.2.10/server/config.c:158

#35 0xb7ef66cf in ap_invoke_handler (r=0xbae277d8) at
/usr/src/debug/httpd-2.2.10/server/config.c:372

#36 0xb7f02ea1 in ap_process_request (r=0xbae277d8) at
/usr/src/debug/httpd-2.2.10/modules/http/http_request.c:258

#37 0xb7effab8 in ap_process_http_connection (c=0xbae1b940) at
/usr/src/debug/httpd-2.2.10/modules/http/http_core.c:190

#38 0xb7efae9d in ap_run_process_connection (c=0xbae1b940) at
/usr/src/debug/httpd-2.2.10/server/connection.c:43

#39 0xb7f082d1 in child_main (child_num_arg=)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:650
#40 0xb7f08599 in make_child (s=, slot=0)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:690
#41 0xb7f092f0 in ap_mpm_run (_pconf=0xb9cfc5c0, plog=0xb9d2a678,
s=0xb9cfe4b8)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:966
#42 0xb7edd7c9 in main (argc=-1177573960, argv=0xbfc18cb4) at
/usr/src/debug/httpd-2.2.10/server/main.c:740

(when selecting a case):

Program received signal SIGSEGV, Segmentation fault.

sYSMALLOc () at malloc.c:3358

3358 set_head(remainder, remainder_size | PREV_INUSE);

(gdb) bt

#0 sYSMALLOc () at malloc.c:3358

#1 _int_malloc (av=0x54f140, bytes=1918986097) at malloc.c:4580

#2 0x00450d5f in _int_realloc (av=0x54f140, oldmem=0xbad35f90,
bytes=1918986098) at malloc.c:5035

#3 0x00451c86 in __libc_realloc (oldmem=0xbad35f90, bytes=1918986098) at
malloc.c:3708

#4 0x00acb759 in Perl_safesysrealloc (where=,
size=1918986098) at util.c:178

#5 0x00de4362 in retrieve_hash (my_perl=0xb9c64a28, cxt=0xb948d59c,
cname=0x0) at Storable.xs:5226

#6 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0)
at Storable.xs:5967

#7 0x00de22a0 in retrieve_ref (my_perl=0xb9c64a28, cxt=0xb948d59c,
cname=0x0) at Storable.xs:4477

#8 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0)
at Storable.xs:5967

#9 0x00de48ad in retrieve_array (my_perl=0xb9c64a28, cxt=0xb948d59c,
cname=0x0) at Storable.xs:5159

#10 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0)
at Storable.xs:5967

#11 0x00de22a0 in retrieve_ref (my_perl=0xb9c64a28, cxt=0xb948d59c,
cname=0x0) at Storable.xs:4477

#12 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0)
at Storable.xs:5967

#13 0x00de42d6 in retrieve_hash (my_perl=0xb9c64a28, cxt=0xb948d59c,
cname=0x0) at Storable.xs:5214

#14 0x00ddfafd in retrieve (my_perl=0xb9c64a28, cxt=0xb948d59c, cname=0x0)
at Storable.xs:5967

#15 0x00de0742 in do_retrieve (my_perl=0xb9c64a28, f=0x0, in=0xbad32f1c,
optype=2) at Storable.xs:6148

#16 0x00de18b4 in mretrieve () at Storable.xs:6264

#17 XS_Storable_mretrieve (my_perl=0xb9c64a28, cv=0xb94893a4) at
Storable.xs:6460

#18 0x00af66f9 in Perl_pp_entersub (my_perl=0xb9c64a28) at pp_hot.c:2847

#19 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931

#20 0x00b65d0f in S_docatch (my_perl=0xb9c64a28, o=) at
pp_ctl.c:2679

#21 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931

#22 0x00aef64d in Perl_call_sv (my_perl=0xb9c64a28, sv=0xbac4266c,
flags=) at perl.c:2631

#23 0x00b93dc8 in Perl_pp_tie (my_perl=0xb9c64a28) at pp_sys.c:850

#24 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931

#25 0x00b65d0f in S_docatch (my_perl=0xb9c64a28, o=) at
pp_ctl.c:2679

#26 0x00b68e4d in Perl_pp_entereval (my_perl=0xb9c64a28) at pp_ctl.c:3617

#27 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931

#28 0x00aef64d in Perl_call_sv (my_perl=0xb9c64a28, sv=0xbac30874,
flags=) at perl.c:2631

#29 0x00b93dc8 in Perl_pp_tie (my_perl=0xb9c64a28) at pp_sys.c:850

#30 0x00ab7f03 in Perl_runops_debug (my_perl=0xb9c64a28) at dump.c:1931

#31 0x00aefa58 in Perl_call_sv (my_perl=0xb9c64a28, sv=0xb96e6084, flags=4)
at perl.c:2646

#32 0x009e6da4 in modperl_callback () from /etc/httpd/modules/mod_perl.so

#33 0x009e7b3c in modperl_callback_run_handlers () from
/etc/httpd/modules/mod_perl.so

#34 0x009e856a in modperl_callback_per_dir () from
/etc/httpd/modules/mod_perl.so

#35 0x009df5ff in ?? () from /etc/httpd/modules/mod_perl.so

#36 0x009df7c5 in modperl_response_handler_cgi () from
/etc/httpd/modules/mod_perl.so

#37 0xb7f03b7d in ap_run_handler (r=0xb98ddfe0) at
/usr/src/debug/httpd-2.2.10/server/config.c:158

#38 0xb7f076cf in ap_invoke_handler (r=0xb98ddfe0) at
/usr/src/debug/httpd-2.2.10/server/config.c:372

#39 0xb7f13ea1 in ap_process_request (r=0xb98ddfe0) at
/usr/src/debug/httpd-2.2.10/modules/http/http_request.c:258

#40 0xb7f10ab8 in ap_process_http_connection (c=0xb98ce138) at
/usr/src/debug/httpd-2.2.10/modules/http/http_core.c:190

#41 0xb7f0be9d in ap_run_process_connection (c=0xb98ce138) at
/usr/src/debug/httpd-2.2.10/server/connection.c:43

#42 0xb7f192d1 in child_main (child_num_arg=)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:650
#43 0xb7f19599 in make_child (s=, slot=0)
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:690
#44 0xb7f1a2f0 in ap_mpm_run (_pconf=0xb87ad5c0, plog=0xb87db678,
s=0xb87af4b8)

—Type to continue, or q to quit—
at /usr/src/debug/httpd-2.2.10/server/mpm/prefork/prefork.c:966
#45 0xb7eee7c9 in main (argc=-1199917640, argv=0xbfd2a5c4) at
/usr/src/debug/httpd-2.2.10/server/main.c:740

I’ve also tried building a 3.8.2 from scratch using Debian-Lenny and got the
same overall effect (didn’t get the GDB traces from that system, but the
symptoms are the same).

Paul Franson

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Paul_Franson · January 28, 2009, 6:43am

You, sir, are a paragon of RT genius!

I did indeed miss the UPGRADING.mysql instructions, and I did, in fact, most definately need them.

That solved my problem and now I can stop pulling my hair out.

Thank you very much!

PaulFrom: Ruslan Zakirov [ruslan.zakirov@gmail.com]
Sent: Tuesday, January 27, 2009 5:56 PM
To: Paul Franson
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Segmentation Fault

I think you have to read UPGRADING.mysql instructions. In mysql
console run “show create table sessions;” and if it has LONGTEXT then
you definitelly must read that file.