Date: Mon, 20 Jan 97 00:33 CST From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: freebsd-hackers@freebsd.org Cc: uhclem@nemesis.lonestar.org Subject: sup dumping core at end of downloading a set Message-ID: <m0vmDIS-000ug2C@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
I have an unusual situation where the FreeBSD port of sup was installed on a DEC Alpha running DEC OSF. With some fiddling around with the Makefile (.if operations don't work and the OSF conditional guarantees a failed build), I got it to compile and it actually downloads files using the FreeBSD cvs-supfile. Sup gets all the way through the first collection and then gets a segmentation fault and dumps core. Restart, it gets to the same point and dies again. Comment out the first collection, start it again and it downloads all of the second collection and then dumps core with the similar message: SUP created directory sup/src-bin for sup/src-bin/when.cvs Segmentation fault (core dumped) The cvs-supfile entries look like: (wrapped for readability) src-bin release=cvs host=sup.FreeBSD.org hostname=/home base=/server/stats/bsdcvs/usr prefix=/server/stats/bsdcvs/home delete old use-rel-suffix /server/stats/bsdcvs/home and /server/stats/bsdcvs/usr exist and are owned by me. The structure was empty when I first invoked sup. There is over 1GB of free disk space. The core file was left in /server/stats/bsdcvs/usr/sup (not where I invoked sup), and it says: dbx version 3.11.10 Type 'help' for help. Core file created by program "sup" signal Segmentation fault at >*[fprintf, 0x3ff800d5ff4] ldq r16, 40(r1) (dbx) tstack Thread 0x3: > 0 fprintf(0xc0080380, 0x140002ca8, 0x1400213a0, 0x11fffdd68, 0x0) [0x3ff800d5ff4] 1 finishone(0x1400213a0, 0x11fffdd68, 0x0, 0x5, 0x12000ee40) [0x12000b7fc] 2 Tsubprocess(0x12000b778, 0x11fffdd68, 0x140003a48, 0x0, 0x0) [0x12000ee3c] 3 Tsubprocess(0x12000b778, 0x11fffdd68, 0x140003a48, 0x0, 0x0) [0x12000ee24] 4 Tsubprocess(0x12000b778, 0x11fffdd68, 0x140003a48, 0x0, 0x0) [0x12000ee24] 5 Tsubprocess(0x12000b778, 0x11fffdd68, 0x140003a48, 0x0, 0x0) [0x12000ee24] 6 Tsubprocess(0x12000b778, 0x11fffdd68, 0x140003a48, 0x0, 0x0) [0x12000ee24] 7 Tsubprocess(0x12000b778, 0x11fffdd68, 0x140003a48, 0x0, 0x0) [0x12000ee24] 8 Tsubprocess(0x12000b778, 0x11fffdd68, 0x140003a48, 0x0, 0x0) [0x12000ee24] 9 Tsubprocess(0x12000b778, 0x11fffdd68, 0x140003a48, 0x0, 0x0) [0x12000ee24] 10 Tsubprocess(0x140003918, 0x3ffc0080380, 0x140001980, 0x140004068, 0x140006b10) [0x12000ee24] 11 Tprocess(0x140001980, 0x140004068, 0x140006b10, 0x140002c90, 0x12000b6c8) [0x12000ef64] 12 finishup(0x1200092e8, 0x1400039d0, 0x1200077f0, 0x140007280, 0x14000d460) [0x12000b6c4] 13 getcoll(0x0, 0xffffffff00000000, 0x0, 0x2, 0x2a30) [0x120007834] 14 main(0x0, 0x1, 0x120004e80, 0x140017020, 0x140010010) [0x1200050c4] (dbx) printregs $vfp= 4831828752 $r0_v0=1 $r1_t0=3221750656 $r2_t1=19922945 $r3_t2=4831828704 $r4_t3=8 $r5_t4=16 $r6_t5=5 $r7_t6=0 $r8_t7=844424930131968 $r9_s0=5368846336 $r10_s1=4831885176 $r11_s2=4831829352 $r12_s3=5368724040 $r13_s4=0 $r14_s5=0 $r15_s6=4710 $r16_a0=3221750656 $r17_a1=5368720552 $r18_a2=5368845216 $r19_a3=4831829352 $r20_a4=0 $r21_a5=5 $r22_t8=19922944 $r23_t9=1048576 $r24_t10=8 $r25_t11=0 $r26_ra=4831885312 $r27_t12=4395899903896 $r28_at=0 $r29_gp=4396973371824 $r30_sp=4831828608 $r31_zero=0 $f0= Denormalized number 0x332c0 $f1= 20960.0 $f2= 0.0 $f3= 0.0 $f4= 0.0 $f5= 0.0 $f6= 0.0 $f7= 0.0 $f8= 0.0 $f9= 0.0 $f10= 0.24834578525933099 $f11= 2.0 $f12= 0.10000000000000001 $f13= 2.0 $f14= Denormalized number 0x1018 $f15= 0.14297193020246479 $f16= INF 0x0000 $f17= Denormalized number 0x51e0 $f18= 0.0 $f19= 1.0 $f20= 0.0 $f21= 0.0 $f22= 0.0 $f23= 0.0 $f24= 0.0 $f25= 0.0 $f26= 0.0 $f27= 0.0 $f28= 0.0 $f29= 0.0 $f30= 0.0 $f31= 0.0 $pc= 4395899903988 $ps= 8 $fpcr=9871890383196127232 (dbx) quit I tried to build cvsup to see if it would work any better, but cvsup won't even build on FreeBSD 2.1.5, much less on OSF. The port expects something called m3build to be on your system, which is NOT the case on a FreeBSD 2.1.5 system installed with the Developer option. Nor is there a word in the port files saying what m3build might be. I consider this a bug in the port. There are other ports that depend on yet-other ports and have the manners to get the pieces they need, or at least have a README or something to tell you that you need this or that. Despite that, I believe this might be some Modula-3 thing, but these additional requirements make it even less likely that I can get cvsup running under OSF. (Attempting to build the Modula-3 port on FreeBSD fails because the Modula-3-lib isn't already present. How far does this go on?) So, I would like to stick with sup for this exercise. Does anyone have any ideas as to why sup would roll over the way it does? I currently don't have the option to run this program under FreeBSD and the OSF system has the disk space. Thanks for any suggestions. Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi" or uhclem%nemesis@rwsystr.nkn.net | demand... A SEGMENT REGISTER!!!" |"A what?" or ...letni!rwsys!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0vmDIS-000ug2C>