Prev: flushing buffer for printing to the screen
Next: floating point issue?
From: efoss on 2 Mar 2010 17:00
I've run into a strange problem. I have a program that is a few
hundred lines long. I run it and it runs fine and gives me the correct
output (at least when I check a few of the output calculations
manually.) But here are some screwy things that disturb me:

1. If I comment out a module that I'm not even using, I get a
"Segmentation fault" error. (The difference is "use FileHandle;"
versus "#use FileHandle;".)

2. If I get the "Segmentation fault" error and then I comment out a
numerical sort of an array (which is working correctly), then the
"Segmentation fault" error goes away.

3. If I run the program on my debugger rather than from a terminal,
the program runs fine.

4. If I run the program on a different computer and run it from a
terminal, the program runs fine.

I don't remember ever getting "Segmentation fault" as an error message
in Perl - I think of that as a "C error", since I've seen it many
times writing C code. Does anyone have an idea what's going wrong?
(I'm not posting the code because it's long and I'm quite certain that
the details of the code won't be relevant, but I'm happy to post it.)

Thanks.

Eric
From: Uri Guttman on 2 Mar 2010 17:13
>>>>> "eo" == efoss(a)fhcrc org <efoss(a)fhcrc.org> writes:

eo> I've run into a strange problem. I have a program that is a few
eo> hundred lines long. I run it and it runs fine and gives me the correct
eo> output (at least when I check a few of the output calculations
eo> manually.) But here are some screwy things that disturb me:

eo> 1. If I comment out a module that I'm not even using, I get a
eo> "Segmentation fault" error. (The difference is "use FileHandle;"
eo> versus "#use FileHandle;".)

FileHandle is obsolete anyhow. never use it. it actually just wraps
IO::Handle. and you rarely need IO::Handle as IO::File or others are
what you want.

eo> 2. If I get the "Segmentation fault" error and then I comment out a
eo> numerical sort of an array (which is working correctly), then the
eo> "Segmentation fault" error goes away.

you are doing something very wrong. hard to divine it with no code.

eo> 3. If I run the program on my debugger rather than from a terminal,
eo> the program runs fine.

eo> 4. If I run the program on a different computer and run it from a
eo> terminal, the program runs fine.

eo> I don't remember ever getting "Segmentation fault" as an error message
eo> in Perl - I think of that as a "C error", since I've seen it many
eo> times writing C code. Does anyone have an idea what's going wrong?
eo> (I'm not posting the code because it's long and I'm quite certain that
eo> the details of the code won't be relevant, but I'm happy to post it.)

perl has rare segment faults. if you can force this everytime, then
report it to p5p (the perl core developers) with the perlbug program.

uri

--
Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
From: Ben Morrow on 2 Mar 2010 17:21

Quoth "efoss(a)fhcrc.org" <efoss(a)fhcrc.org>:
> I've run into a strange problem. I have a program that is a few
> hundred lines long. I run it and it runs fine and gives me the correct
> output (at least when I check a few of the output calculations
> manually.) But here are some screwy things that disturb me:
>
> 1. If I comment out a module that I'm not even using, I get a
> "Segmentation fault" error. (The difference is "use FileHandle;"
> versus "#use FileHandle;".)

A segfault is *always* a bug in perl, or in an XS module. This symptom
you describe, of the problem going away when random things are changed
slightly, probably indicates some sort of memory allocation error. If a
piece of code somewhere is (say) dereferencing a pointer after it's been
freed, whether that will segfault or not depends on whether that piece
of memory has been reused yet, and that in turn depends on the exact
details of what has been allocated so far.

Things to try, in order:
- Try it with 5.10.1, in case the bug has been found and fixed. Try
it with the latest versions of any XS modules you are using, for
the same reason.

- Get the 5.11.5 source tarball, build perl with -DDEBUGGING, and
try it with that. If it still fails you're likely to get an
assertion failure much nearer the real bug.

- If you're up to it, provoke a failure under gdb and attempt to
work out what's going on, or run perl under valgrind to check for
allocation errors.

- Report a bug, including as much detail as you can. You need to cut
as much as you can out of your test case without making the
failure go away. This can be tedious, especially with a heisenbug
like this.

Ben

From: efoss on 2 Mar 2010 18:05
On Mar 2, 2:21 pm, Ben Morrow <b...(a)morrow.me.uk> wrote:
> Quoth "ef...(a)fhcrc.org" <ef...(a)fhcrc.org>:
>
> > I've run into a strange problem. I have a program that is a few
> > hundred lines long. I run it and it runs fine and gives me the correct
> > output (at least when I check a few of the output calculations
> > manually.) But here are some screwy things that disturb me:
>
> > 1. If I comment out a module that I'm not even using, I get a
> > "Segmentation fault" error. (The difference is "use FileHandle;"
> > versus "#use FileHandle;".)
>
> A segfault is *always* a bug in perl, or in an XS module. This symptom
> you describe, of the problem going away when random things are changed
> slightly, probably indicates some sort of memory allocation error. If a
> piece of code somewhere is (say) dereferencing a pointer after it's been
> freed, whether that will segfault or not depends on whether that piece
> of memory has been reused yet, and that in turn depends on the exact
> details of what has been allocated so far.
>
> Things to try, in order:
>     - Try it with 5.10.1, in case the bug has been found and fixed. Try
>       it with the latest versions of any XS modules you are using, for
>       the same reason.
>
>     - Get the 5.11.5 source tarball, build perl with -DDEBUGGING, and
>       try it with that. If it still fails you're likely to get an
>       assertion failure much nearer the real bug.
>
>     - If you're up to it, provoke a failure under gdb and attempt to
>       work out what's going on, or run perl under valgrind to check for
>       allocation errors.
>
>     - Report a bug, including as much detail as you can. You need to cut
>       as much as you can out of your test case without making the
>       failure go away. This can be tedious, especially with a heisenbug
>       like this.
>
> Ben

Thanks very much. I just tried the first one - installing Perl 5.10.1.
I had 5.10.0 before, which I checked with "perl -v". I then went
here:

http://www.activestate.com/activeperl/downloads/

and I downloaded the recommended version. (I'm using MacOS X with the
Snowleopard operating system.) Below is what it said it recommended:

Recommended version(s) for your platform:
ActivePerl 5.10.1.1007 for Mac OS X (Universal)

I then restarted my computer and tried again and got the same error.
However, then when I tried "perl -v" again, it said that I was using
5.10.0 rather than 5.10.1. I'm puzzled by this, since installing perl
was pretty straight forward - just clicking "next" a bunch of times
and accepting all the default settings. I'll screw around more with
this to see if I can figure out what I'm doing wrong.

Thanks again for your help.

Eric

From: Ben Morrow on 2 Mar 2010 19:10

Quoth "efoss(a)fhcrc.org" <efoss(a)fhcrc.org>:
>
> Thanks very much. I just tried the first one - installing Perl 5.10.1.
> I had 5.10.0 before, which I checked with "perl -v". I then went
> here:
>
> http://www.activestate.com/activeperl/downloads/
>
> and I downloaded the recommended version. (I'm using MacOS X with the
> Snowleopard operating system.) Below is what it said it recommended:
>
> Recommended version(s) for your platform:
> ActivePerl 5.10.1.1007 for Mac OS X (Universal)

Hmmm. I wouldn't recommend AS Perl for Mac OS (or Win32 nowadays, for
that matter). Building perl from source is not difficult: install the
dev tools (last time I had anything to do with Mac OS they were on the
third or fourth install CD), download the tarball, untar it and run

./Configure -des
make
make test
make install

This will install the new perl into /usr/local/bin, which is correct
(see below). You realy don't want to overwrite Apple's perl in /usr/bin.

> I then restarted my computer and tried again and got the same error.
> However, then when I tried "perl -v" again, it said that I was using
> 5.10.0 rather than 5.10.1. I'm puzzled by this, since installing perl
> was pretty straight forward - just clicking "next" a bunch of times
> and accepting all the default settings. I'll screw around more with
> this to see if I can figure out what I'm doing wrong.

Your PATH environment variable is set wrong. If you type 'which perl' it
will tell you you are using /usr/bin/perl, which is Apple's perl. You
need to find out where AS perl gets installed (it might be
/usr/local/bin, it might not...) and prepend that directory to your
PATH.

Ben

 |  Next  |  Last
Pages: 1 2
Prev: flushing buffer for printing to the screen
Next: floating point issue?