Bus error -- Re: [mapserver-users] Re: Perl/mapscript error

Lowell Filak lfilak at medinaco.org
Mon Apr 29 14:58:32 PDT 2002 

I believe I have the full picture now. Here is what I'm looking at:
The initial error is not in mapscript.pm but results in a fatal error because the type being sent back to DESTROY is a scalar instead of a hash and perl proceeds to try to handle it as a hash. I think the real problem is why did a scalar come back. Is it because of a misfire in mapscript_wrap.c via SWIG? I don't believe anything should return a scalar because the objects are built as hashes from the start.
Lowell F.

The following message was sent by Puneet Kishor <pkishor at GeoAnalytics.com> on Mon, 29 Apr 2002 14:41:27 -0500.

> Hi Lowell,
> 
> My problem is specifically in mapObj... the DESTROY sub in the mapObj. The
> error message you refer to is the only error message.
> 
> You asked for my map file... I can send you the file, but it is really a
> very simple map file. The problem is not with that... the problem is with
> some error trapping... I have got my perl code/map file/data combo working
> now. However, if something goes wrong in my code, this error crops up.
> 
> here is what I have gathered...
> 
> if I make some mistake in my coding, mapscript.pm is unable to recover from
> it... in other words, while the actual error is not in the mapscript.pm
> code, it is the mapscript.pm code that croaks because the mapObj that it is
> trying to DESTROY doesn't exist anymore.
> 
> Btw, this is not necessarily a mapscript.pm specific thing... that is, there
> are others who have experienced such an error with other scripts. This is
> also not an OS specific thing... I posted an inquiry about "bus error" on
> perl at macosx and a few there have seen this crop up here and there. But, note
> that Giorgio also experienced this error... I am assuming he is not using OS
> X.
> 
> In other words, there is some assertion checking or error-trapping that can
> be implemented in mapscript.pm which will cause DESTROY to not fail if the
> object it is trying to destroy (in this case, mapObj) doesn't exist. This
> way mapscript.pm can fail gracefully, and not cause a fatal error for Perl
> altogether.
> 
> Thanks,
> 
> pk/
> 
> 
> 
> > -----Original Message-----
> > From: Lowell Filak [mailto:lfilak at medinaco.org]
> > Sent: Monday, April 29, 2002 2:44 PM
> > To: Puneet Kishor; Giorgio Volpe
> > Cc: mapserver-users at lists.gis.umn.edu
> > Subject: Re: Bus error -- Re: [mapserver-users] Re: 
> > Perl/mapscript error
> > 
> > 
> > Any gurus feel free to step forward, in the mean-time I have 
> > a couple of questions:
> > Puneet - is "(in cleanup) Not a HASH reference at 
> > /Library/Perl/darwin/mapscript.pm ine 1468." the ONLY error 
> > message in your log? Are there ANY other messages in the log 
> > around the same time (within a second or so)?
> > Giorgio - which DESTROY subroutine did you insert your print 
> > statement into, mapObj, layerObj, classObj, ...? It looks 
> > like layerObj as opposed to mapObj where Puneet is having trouble.
> > Lowell F.
> > 
> > The following message was sent by Puneet Kishor 
> > <pkishor at GeoAnalytics.com> on Sun, 28 Apr 2002 10:29:51 -0500.
> > 
> > > thanks for analysis Giorgio... I will try out some of your 
> > shenanigans 
> > > detailed here...
> > > 
> > > since it has not been reported exhaustively, I guess there 
> > is something 
> > > about our implementation that is bringing this out. My 
> > guess is so... if 
> > > there is an error in the Perl script (because of our own 
> > programming 
> > > mistake), the script goes kablooie and the map object 
> > vanishes without a 
> > > warning. However, the coded garbage collector tries to clean it up, 
> > > except it doesn't find anything. So, it croaks.
> > > 
> > > >
> > > > We need a PERL guru ...!
> > > 
> > > I think we already have a few on this list, probably 
> > starting with Steve 
> > > Lime at the very top considering he wrote most of this 
> > wizardry to begin 
> > > with... I am sure between him and Steve W and Lowell and 
> > Paul Ramsey, 
> > > etc., we will be able to squash this.
> > > 
> > > pk/
> > > 
> > > 
> > > 
> > > 
> > > On Sunday, April 28, 2002, at 10:20  AM, Giorgio Volpe wrote:
> > > 
> > > > Puneet Kishor wrote:
> > > >>
> > > >> ok... I have spent a good part of today battling this, and have
> > > >> discovered the following...
> > > >>
> > > >> one of the reasons I am getting these errors because I 
> > have -w switch 
> > > >> on
> > > >> my shebang line. After much finagling, I can get the 
> > image to draw, but
> > > >> with the -w switch I get the following error as well --
> > > >>
> > > >> (in cleanup) Not a HASH reference at 
> > /Library/Perl/darwin/mapscript.pm
> > > >> line 1468.
> > > >>
> > > >> that line in mapscript.pm is the one that is trying to 
> > clean up... and
> > > >> failing. Specifically,
> > > >>
> > > >> sub DESTROY {
> > > >>      my $self = tied(%{$_[0]});
> > > >>      delete $ITERATORS{$self};
> > > >>      if (exists $OWNER{$self}) {
> > > >>          mapscriptc::delete_mapObj($self);
> > > >>          delete $OWNER{$self};
> > > >>      }
> > > >> }
> > > >
> > > > I've the same problem!
> > > > It is not a warning but a fatal error for perl.
> > > >
> > > > The problem, i guess, is related to the use of tied hash 
> > to support
> > > > mapscript objects ...
> > > >
> > > > I've added a PRINT ...
> > > >
> > > > sub DESTROY {
> > > >     print STDERR "!!!! Destroing $_[0] ...\n";
> > > >     my $self = tied(%{$_[0]});
> > > >     ...
> > > >
> > > > The DESTRUCTOR is called two times! The first one with 
> > $_[0] that is a
> > > > reference to an hash, the second to a scalar so function 
> > "tied" raises
> > > > the error!
> > > >
> > > > !!!! Destroing layerObj=HASH(0x83e925c) ...
> > > > !!!! Destroing layerObj=SCALAR(0x83d8ef4) ...
> > > >
> > > > Empirically i've seen that, if I undef the variable containing the
> > > > reference to the object before returning from the sub 
> > where i use it,
> > > > than the error disappears ... (also if the two call to 
> > the DESTRUCTOR
> > > > are always there, but probably the undef value is passed)
> > > >
> > > >
> > > > We need a PERL guru ...!
> > > >
> > > > --
> > > >
> > > >     Giorgio
> > > >
> > > > -----------------------------------------
> >

More information about the MapServer-users mailing list