talexb has asked for the wisdom of the Perl Monks concerning the following question:

For some reason, a module that has worked well over the past while is now causing a segmentation fault at the following statement: 
dograph::Create(/home/fininfo/htdocs/perllib/dograph.pm:699):
699:      unless ( open ( GP_FILE, ">$TempGP" ) )
700:      {
  DB<5> s
Segmentation fault

[download]
The contents of $TempGP are perfectly normal .. a path to an output file that will be used to do a GnuPlot. This code works find for approximately 4000 other company symbols but fails on this one.

I tried stepping into open and of course that didn't work. The file does not already exist, the directory is writable, the disk has 60% of its space available, and I used this script to create about 4000 x 5 graphs earlier today.

Can anyone suggest why I'd get a segmentation fault during an open operation?

--t. alex

"There was supposed to be an earth-shattering kaboom!" --Marvin the Martian

Replies are listed 'Best First'.
Re: Segmentation fault during file open
by Zaxo (Archbishop) on Mar 05, 2002 at 20:37 UTC

    A couple of things to try:

    1. run under strace to get some better clues and a look at the call stack.
    2. Find out if any libraries were upgraded in the meantime. Shouldn't break things, but sometimes...
    If the module's been working, I doubt that it's suddenly begun passing around null pointers, Could you be handing it a bogus reference?

    After Compline,
    Zaxo

[reply]
      Cool .. never tried strace before. Here's the tail end of what I got: 
      write(2, "print on closed filehandle main:"..., 94print on closed file
+handle main::STDBUG at /usr/local/lib/site_perl/CGI/LogCarp.pm line 1
+516.
) = 94
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
write(2, "[Tue Mar  5 18:35:43 2002]  1789"..., 129[Tue Mar  5 18:35:4
+3 2002]  17898 mgtemp.pl ERR: Use of uninitialized value at /home/fin
+info/htdocs/perllib/dograph.pm line 622.
) = 129
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
open("/var/MPL/tmp/dailyen/C/CYS04.gp", O_WRONLY|O_CREAT|O_TRUNC, 0666
+ <unfinished ...>
+++ killed by SIGSEGV +++

      [download]
      I know about the undefined value and I've been meaning to fix it, but it occurs in all of the other symbols and it doesn't kill them. Why is the open unfinished?

      Maybe I'll go fix that 'undefined' problem and try this all again.

      --t. alex

      "There was supposed to be an earth-shattering kaboom!" --Marvin the Martian

[reply]
[d/l]
[select]
      OK, fixed the undefined value problem (someone else had commented out one of my lines of code). Now the tail end of the strace output is 
      read(5, "\n2002-02-28\0050.020\0050.020\0050.020\0050."..., 92) = 92
read(5, "\\\0\0?", 4)                   = 4
read(5, "\n2002-03-05\0050.020\0050.020\0050.020\0050."..., 92) = 92
read(5, "\1\0\0@", 4)                   = 4
read(5, "\376", 1)                      = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
write(9, "# dograph version 12:51 2 Novemb"..., 4002) = 4002
close(9)                                = 0
munmap(0x2aac0000, 4096)                = 0
open("/var/MPL/tmp/dailyen/C/CYS04.gp", O_WRONLY|O_CREAT|O_TRUNC, 0666
+ <unfinished ...>
+++ killed by SIGSEGV +++

      [download]
      Thoughts?

      Update at 2222: Also tried changing the unless to an open .. || return .. in the extremely unlikely event that that would make a difference. No dice.

      --t. alex

      "There was supposed to be an earth-shattering kaboom!" --Marvin the Martian

[reply]
[d/l]
[select]

        That's coming from within the libc open call. If you have debugging libc installed, running under gdb may help. Perl should not be able to do this to the system.1 What is your libc, OS and their patchlevels? One recent Linux release "featured" an fs corruption bug, so maybe booting a known good kernel is called for. A bad sector or corrupt inode could do this, so I think ehdonhon's suggestion of a fsck is a good idea at this point.

        If you're not getting core dumps for gdb, you can try $SIG{SEGV} = sub{abort};. You will want the source of libc open() to know what names to look at.

        The filesystem theory really doesn't fit crashing on the same file each time. I am puzzled..

        1 Update: Overstated, withdrawn.

        After Compline,
        Zaxo

[reply]
[d/l]
Re: Segmentation fault during file open
by ehdonhon (Curate) on Mar 05, 2002 at 20:37 UTC

    Try running fsck on the drive?

    If you have ktrace available, you might want to ktrace the execution and see if it has anything useful to say. The other option is to make sure you have perl compiled with debugging symbols enabled, and then run gdb on the core file that gets dumped.

[reply]
Re: Segmentation fault during file open
by ajwans (Scribe) on Mar 05, 2002 at 22:05 UTC
    What is in the variable $TempGP?
[reply]
      The variable $TempGP contains /var/MPL/tmp/dailyen/C/CYS04.gp -- there are plenty of other examples where this code works, it just appears that for this company symbol the code seg faults.

      --t. alex

      "There was supposed to be an earth-shattering kaboom!" --Marvin the Martian

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom