Re: seg faults when i use thread->new from a thread - am i using threads incorrectly?
[email protected] ("Bradley W. Langhorst")
| Newsgroups | perl.ithreads |
|---|---|
| Message-ID | <1049295314.1957.46.camel@bwlnote> |
On Wed, 2003-04-02 at 08:47, Arthur Bergman wrote: > This has been known to be a bit wonky on Win32, but not under unix > (which I assume you are using because you like forks.pm) > that's correct - i'm using linux 2.4.20 > > A backtrace would be nice,, > > gdb perl > run ./agent.pl > bt Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 147458 (LWP 24211)] 0x401fa3f2 in sharedsv_elem_mg_dup () from /usr/lib/perl/5.8.0/auto/threads/shared/shared.so (gdb) bt #0 0x401fa3f2 in sharedsv_elem_mg_dup () from /usr/lib/perl/5.8.0/auto/threads/shared/shared.so #1 0x080c421e in Perl_mg_dup () #2 0x080c4a88 in Perl_sv_dup () #3 0x080c4eae in Perl_sv_dup () #4 0x080c4eae in Perl_sv_dup () #5 0x080c53ca in Perl_sv_dup () #6 0x080c40ac in Perl_gp_dup () #7 0x080c5565 in Perl_sv_dup () #8 0x080c4eae in Perl_sv_dup () #9 0x080c4eae in Perl_sv_dup () #10 0x080c53ca in Perl_sv_dup () #11 0x080c40ac in Perl_gp_dup () #12 0x080c5565 in Perl_sv_dup () #13 0x080c4eae in Perl_sv_dup () #14 0x080c4eae in Perl_sv_dup () #15 0x080c53ca in Perl_sv_dup () #16 0x080c4588 in Perl_rvpv_dup () #17 0x080c4803 in Perl_sv_dup () #18 0x080abcb1 in Perl_he_dup () #19 0x080c5112 in Perl_sv_dup () #20 0x080c4eae in Perl_sv_dup () #21 0x080c4eae in Perl_sv_dup () ---Type <return> to continue, or q <return> to quit--- #22 0x080c53ca in Perl_sv_dup () #23 0x080c534d in Perl_sv_dup () #24 0x080c534d in Perl_sv_dup () #25 0x080c40ac in Perl_gp_dup () #26 0x080c5565 in Perl_sv_dup () #27 0x080abcb1 in Perl_he_dup () #28 0x080abc62 in Perl_he_dup () #29 0x080c5112 in Perl_sv_dup () #30 0x080c5245 in Perl_sv_dup () #31 0x080c40ac in Perl_gp_dup () #32 0x080c5565 in Perl_sv_dup () #33 0x080abcb1 in Perl_he_dup () #34 0x080c5112 in Perl_sv_dup () #35 0x080c4aa0 in Perl_sv_dup () #36 0x080c4588 in Perl_rvpv_dup () #37 0x080c4803 in Perl_sv_dup () #38 0x080c418b in Perl_mg_dup () #39 0x080c4da8 in Perl_sv_dup () #40 0x080c4588 in Perl_rvpv_dup () #41 0x080c4803 in Perl_sv_dup () #42 0x080c4f15 in Perl_sv_dup () #43 0x080c4060 in Perl_gp_dup () #44 0x080c5565 in Perl_sv_dup () ---Type <return> to continue, or q <return> to quit--- #45 0x080c4eae in Perl_sv_dup () #46 0x080c4eae in Perl_sv_dup () #47 0x080c53ca in Perl_sv_dup () #48 0x080c40ac in Perl_gp_dup () #49 0x080c5565 in Perl_sv_dup () #50 0x080abcb1 in Perl_he_dup () #51 0x080c5112 in Perl_sv_dup () #52 0x080c553b in Perl_sv_dup () #53 0x080c6755 in perl_clone () #54 0x401f3bdb in Perl_ithread_create () from /usr/lib/perl/5.8.0/auto/threads/threads.so #55 0x401f4101 in XS_threads_new () from /usr/lib/perl/5.8.0/auto/threads/threads.so #56 0x080b6f47 in Perl_pp_entersub () #57 0x080b17ee in Perl_runops_standard () #58 0x0806276a in Perl_call_sv () #59 0x08062529 in Perl_call_sv () #60 0x401f369b in Perl_ithread_run () from /usr/lib/perl/5.8.0/auto/threads/threads.so #61 0x40049d53 in pthread_start_thread () from /lib/libpthread.so.0 #62 0x40049d99 in pthread_start_thread_event () from /lib/libpthread.so.0 zoiks - that is a long back trace... you may be wondering why so many calls sv_grp and mg_dup... Im sharing 4 variables between threads 1) fairly complex multi-d hash containing arrays 2) straighforward 2-d hash 3) an array of hashes 4) a hash of arrays I can show you the structures if you like > Do you know when you are getting the coredump, in new() or in join? it's in the new (exclusively as far as i can tell) - i see a log message right before the new but not the one right after... > > Also, what modules are you using? here are my use statements... use strict; use IO::Socket; use Carp; #could do without this... use threads; use threads::shared; #use forks; #use forks::shared; use Fcntl qw(:DEFAULT :flock); #for locking the log file use Data::Dumper; #for debugging - don't really need this. Thanks for your attention to this - i'll do whatever i can to help find the problem... brad -- Bradley W. Langhorst <[email protected]>