Prev: FreeBSD Port: nss-pam-ldapd-0.7.7
Next: General note on rc scripts and daemonizing
From: Janne Snabb on 17 Jul 2010 04:11
Hi,

Same problem here.

Here is the gdb output:

#0 0x00000000004ddbd3 in Perl_safesyscalloc (count=1, size=4072) at util.c:311
311 DEBUG_m(PerlIO_printf(Perl_debug_log, "0x%"UVxf": (%05ld) calloc %ld x %ld bytes\n",PTR2UV(ptr),(long)PL_an++,(long)count,(long)total_size));
(gdb) bt
#0 0x00000000004ddbd3 in Perl_safesyscalloc (count=1, size=4072) at util.c:311
#1 0x000000000054a28f in Perl_get_arena (my_perl=0x801002500,
arena_size=3880, bodytype=SVt_PV) at sv.c:737
#2 0x000000000054a584 in S_more_bodies (my_perl=0x801002500, sv_type=SVt_PV)
at sv.c:1104
#3 0x000000000054b829 in Perl_sv_upgrade (my_perl=0x801002500,
sv=0x801002c98, new_type=SVt_PV) at sv.c:1398
#4 0x00000000005722ff in Perl_sv_setpv (my_perl=0x801002500, sv=0x801002c98,
ptr=0x791d5a "") at sv.c:4387
#5 0x0000000000748695 in perl_construct (my_perl=0x801002500) at perl.c:254
#6 0x000000000071e6a7 in main (argc=3, argv=0x7fffffffe368,
env=0x7fffffffe388) at miniperlmain.c:111

It is somehow related to the "Perl_debug_log" which is the first
argument of PerlIO_printf. But I can not figure out why, too many
layers of #defines and calls within calls.

If I insert a line which references Perl_debug_log before the
problematic line, it will dump core on that line, gdb output:

Program received signal SIGSEGV, Segmentation fault.
0x00000000006f2de0 in Perl_PerlIO_stderr (my_perl=0x0) at perlio.c:4981
4981 if (!PL_perlio) {

I cannot inspect PL_perlio because it is another macro, from perlapi.h:

#define PL_perlio (*Perl_Iperlio_ptr(aTHX))

aTHX is defined in perl.h to be my_perl, which seems to be a null
pointer:

(gdb) p my_perl
$1 = (PerlInterpreter *) 0x0

So, the miniperl process dies because it cannot de-reference this
NULL pointer. I have no clue where it should be initialized.

--
Janne Snabb / EPIPE Communications
snabb(a)epipe.com - http://epipe.com/
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Janne Snabb on 17 Jul 2010 05:23
On Sat, 17 Jul 2010, Janne Snabb wrote:

> It is somehow related to the "Perl_debug_log" which is the first
> argument of PerlIO_printf. But I can not figure out why, too many
> layers of #defines and calls within calls.

The problem seems to go away when threads are disabled.

The problematic line 311 in util.c expands to quite a horrible mess
(found this out by doing make util.i):

(void)( { if ((PL_curinterp)) { PerlInterpreter* my_perl __attribute__((unused)) = ((PerlInterpreter *)pthread_getspecific(PL_thr_key)); if (((my_perl->Idebug) & 0x00000080)) {(my_perl->Idebug)&=~0x00000080; PerlIO_printf(Perl_PerlIO_stderr(my_perl), "0x%""lx"": (%05ld) calloc %ld x %ld bytes\n",(UV)(ptr),(long)(my_perl->Ian)++,(long)count,(long)total_size); (my_perl->Idebug)|=0x00000080;} } } );

The problem is that my_perl here is NULL pointer. PL_thr_key which
is given to pthread_getspecific() to get my_perl is zero.

(gdb) p my_perl
$1 = (PerlInterpreter *) 0x0
(gdb) p PL_thr_key
$2 = 0
(gdb)

Someone who understands the perl threading internals needs to figure
this out.

--
Janne Snabb / EPIPE Communications
snabb(a)epipe.com - http://epipe.com/
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Lupe Christoph on 17 Jul 2010 08:24
On Saturday, 2010-07-17 at 09:23:18 +0000, Janne Snabb wrote:

> The problem seems to go away when threads are disabled.

> The problematic line 311 in util.c expands to quite a horrible mess
> (found this out by doing make util.i):

> (void)( { if ((PL_curinterp)) { PerlInterpreter* my_perl __attribute__((unused)) = ((PerlInterpreter *)pthread_getspecific(PL_thr_key)); if (((my_perl->Idebug) & 0x00000080)) {(my_perl->Idebug)&=~0x00000080; PerlIO_printf(Perl_PerlIO_stderr(my_perl), "0x%""lx"": (%05ld) calloc %ld x %ld bytes\n",(UV)(ptr),(long)(my_perl->Ian)++,(long)count,(long)total_size); (my_perl->Idebug)|=0x00000080;} } } );

> Someone who understands the perl threading internals needs to figure
> this out.

I would recommend you take this to the perl5-porters mailing list. You
will have a much better chance of finding expertise than on this mailing
list.

perl5-porters(a)perl.org

HTH,
Lupe Christoph
--
| It is a well-known fact in any organisation that, if you want a job |
| done, you should give it to someone who is already very busy. |
| Terry Pratchett, "Unseen Academicals" |
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Janne Snabb on 17 Jul 2010 20:58
> On Saturday, 2010-07-17 at 09:23:18 +0000, Janne Snabb wrote:
>
>> The problem seems to go away when threads are disabled.

The problem appears on i386 in addition to amd64, probably other
architectures as well.

My advice would be: DO NOT try to upgrade your perl to 5.12 if you
are using threads (which are not enabled by default).

On Sat, 17 Jul 2010, Lupe Christoph wrote:

> I would recommend you take this to the perl5-porters mailing list. You
> will have a much better chance of finding expertise than on this mailing
> list.

Done. Does not show up yet though. Maybe it is sitting in some
moderation queue.

--
Janne Snabb / EPIPE Communications
snabb(a)epipe.com - http://epipe.com/
_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

From: Christopher Key on 18 Jul 2010 23:46
cjk32(a)cam.ac.uk wrote:
> Someone who understands the perl threading internals needs to figure
> this out.
>
>
Simple solution, there was a missing -lpthread, patch available from:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148648


For some reason, linking binaries without -lpthread succeeds, but the
pthread calls in the resulting binary do nothing.

#v+
# cat pthread.c
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

int main(void) {

int i;
pthread_key_t k;

k = 1234;
i = pthread_key_create(&k, NULL);
fprintf(stderr, "%d %d\n", i, (int) k);

return 0;

}
# gcc pthread.c -o pt1
# gcc pthread.c -lpthread -o pt2
# ./pt1
0 1234
# ./pt2
0 0
#v-

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

 |  Next  |  Last
Pages: 1 2 3
Prev: FreeBSD Port: nss-pam-ldapd-0.7.7
Next: General note on rc scripts and daemonizing