keith@curry.uchicago.edu (Keith Waclena) (08/17/90)
Well, I've been waiting to see if anybody else was going to report
this, but it looks like I'm going to be the first.
Perl at PL 27 and also at PL 28 both fail op.dbm, dumping core in a
big way. Here is a trivial script that illustrates the problem:
dbmopen(FOO, "Foo", 0644) || die "Whoops.. $!\n";
$FOO{123} = 1;
It blows up in the assignment. Single stepping in GDB shows that the
core dump occurs in dbm_store! All the args to the dbm_store look
fine (as fas as I can tell...). Perl at PL 18 handle dbm stuff just
fine; in fact I have a large investment in Perl code that uses dbm
heavily. Sorta cramps my style...
Anyway, my environment is Sun SparcStation-1 running SunOS Release
4.0.3. I compiled with both Sun's cc and Gnu cc; same results. Also
blows up on a Sun 4/110 running SunOS 4.0.
As a test, I changed Perl to use Gnu dbm, and it works! This isn't
helpful though as now all my huge dbm indices are incompatible. I
repeat that Sun's ndbm always worked up through PL 18.
Any help would be greatly appreciated!
--
Keith WACLENA keith@tira.uchicago.edu
CILS / TIRA / U of Chicago keith%tira@uchimvs1.bitnet
1100 E.57th.St Chi IL 60637 USA ...!uunet!tira.uchicago.edu!keithjw@sics.se (Johan Widen) (08/17/90)
>>>>> In article <1990Aug17.031514.14790@midway.uchicago.edu>, keith@curry.uchicago.edu (Keith Waclena) writes:
keith> Well, I've been waiting to see if anybody else was going to report
keith> this, but it looks like I'm going to be the first.
keith> Perl at PL 27 and also at PL 28 both fail op.dbm, dumping core in a
keith> big way. Here is a trivial script that illustrates the problem:
It works for me. Both PL27 and PL28 passed op.dbm. The only change I made was
undef VFORK (I do not know if that is needed, any more. It helped in earlier
versions, I have not tried PL28 or PL27 with VFORK defined on the Sparc).
I use gcc and we are running SunOS 4.0.3.
--
Johan Widen
SICS, PO Box 1263, S-164 28 KISTA, SWEDEN Internet: jw@sics.se
Tel: +46 8 752 15 32 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30ajudge@maths.tcd.ie (Alan Judge) (08/22/90)
In <1990Aug17.031514.14790@midway.uchicago.edu> keith@curry.uchicago.edu (Keith Waclena) writes: >Perl at PL 27 and also at PL 28 both fail op.dbm, dumping core in a >big way. Here is a trivial script that illustrates the problem: > dbmopen(FOO, "Foo", 0644) || die "Whoops.. $!\n"; > $FOO{123} = 1; >It blows up in the assignment. Single stepping in GDB shows that the >core dump occurs in dbm_store! All the args to the dbm_store look >fine (as fas as I can tell...). Perl at PL 18 handle dbm stuff just >fine; in fact I have a large investment in Perl code that uses dbm >heavily. Sorta cramps my style... >Anyway, my environment is Sun SparcStation-1 running SunOS Release >4.0.3. I compiled with both Sun's cc and Gnu cc; same results. Also >blows up on a Sun 4/110 running SunOS 4.0. I am running perl PL 28 on a Sun SS-1/4.0.3c, and op.dbm (and all the other tests) works fine for me. I suggest you check your patches/sources etc... I compiled perl with cc. -- Alan Judge ajudge@maths.tcd.ie a.k.a. amjudge@cs.tcd.ie +353-1-772941 x1782 If you make it possible for programmers to write in English, you will discover that they can't.
csu@alembic.acs.com (Dave Mack) (08/24/90)
In article <1990Aug21.203346.598@maths.tcd.ie> ajudge@maths.tcd.ie (Alan Judge) writes: >In <1990Aug17.031514.14790@midway.uchicago.edu> keith@curry.uchicago.edu (Keith Waclena) writes: >>Perl at PL 27 and also at PL 28 both fail op.dbm, dumping core in a >>big way. Here is a trivial script that illustrates the problem: >>Anyway, my environment is Sun SparcStation-1 running SunOS Release >>4.0.3. I compiled with both Sun's cc and Gnu cc; same results. Also >>blows up on a Sun 4/110 running SunOS 4.0. > >I am running perl PL 28 on a Sun SS-1/4.0.3c, and op.dbm (and all the other >tests) works fine for me. I suggest you check your patches/sources etc... > >I compiled perl with cc. Me too, on a Sun-4/110 running SunOS4.1, and it also passes op.dbm. Unfortunately, it appears that delete, when applied to an assoc array (from dbm), deletes the wrong entry in the database. In particular, this code, which worked perfectly under Perl3.18, very quietly does the wrong thing: #! /usr/local/bin/perl # # rmbyalias deletes an entry from real2alias database given the alias # # Usage: rmbyalias <alias> # umask 0077; if ( $#ARGV != 0 ) { print STDERR "Usage: rmbyalias <alias>\n"; exit(1); } $target_alias = $ARGV[0]; dbmopen(r2a,"/usr/personals/real2alias",0600) || die "$0: can't dbmopen real2alias: $!\n"; open(LOG,">>/usr/personals/REMOVED"); while (($key,$value) = each %r2a) { if ( "$value" eq "$target_alias" ) { delete $r2a{$key}; print LOG "$value:$key\n"; print "Removed $value:$key\n"; } } dbmclose(r2a); close(LOG); exit(0); Further context: in SunOS4.1, libdbm.a (according to the man page) is actually ndbm. I have no idea whether or not this is relevant. -- Dave Mack csu@alembic.ACS.COM
merlyn@iwarp.intel.com (Randal Schwartz) (08/25/90)
In article <1990Aug24.061936.7472@alembic.acs.com>, csu@alembic (Dave Mack) writes: | Me too, on a Sun-4/110 running SunOS4.1, and it also passes op.dbm. | Unfortunately, it appears that delete, when applied to an assoc | array (from dbm), deletes the wrong entry in the database. | | In particular, this code, which worked perfectly under Perl3.18, | very quietly does the wrong thing: [and don't the hundreds of alt.personals readers know it!!] Larry (who is probably posting the very same response) told me that it was a problem introduced by an optimization he made in the last megapatch that makes "defined %foo" be false until its first assignment (because someone complained about that). Unfortunately, he missed that a dbmopen(foo,...) is an assignment, and so the data structures never got initialized. The workaround until the next patch is to assign an artificial value right after the dbmopen and then delete it back out (I hope that's what he said :-). I think somebody else already pointed that out too. $JAPH = "print 'Just another Perl hacker,'"; eval $JAPH -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/
ripley@opal.cs.tu-berlin.de (Hans-Ch. Eckert) (08/27/90)
Hello. I ftp'ed the Perl/PL28-sources from cs.uni-sb.de, unpacked them invoked Configure and make and finally make test. No trouble at all. Except some paths, I answered all questions from Configure with CR. I got some compiler-barfing at one source-file though. I was astonished to get a working binary at the end, but the heck I say ;-) I did tihs on Sun4/xx and Sun3/xx both running SunOS 4.1... Greetings, RIPLEY PS: Is there any danger in stripping the resulting binaries? They're huge. -- Greetings from RIPLEY | UUCP: ripley@tubopal.UUCP (ripley@opal.cs.tu-berlin.de) Hans-Christian Eckert | ...!unido!tub!opal!ripley (Europe) D-1000 Berlin 30 | ...!pyramid!tub!opal!ripley (World) Regensburger Str. 2 | BITNET: ripley%tubopal@DB0TUI11.BITNET (saves $$$)
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (08/27/90)
In article <RIPLEY.90Aug27024518@troll.cs.tu-berlin.de> ripley@opal.cs.tu-berlin.de (Hans-Ch. Eckert) writes:
: PS: Is there any danger in stripping the resulting binaries? They're huge.
As long as you don't want to run a C debugger or undump, there's no problem.
Larry