Subject: sdr coredumps/sunos 4.1.4

From: Len Rose <[email-masked]>
Date: Thu, 21 Nov 1996 22:13:29 -0800

Has anyone noted a problem with SunOS 4.1.4 and sdr 2.3a1? I seem to
be unable to bring it up without core dumping...

Thanks

Len

[email-masked]
http://www.netsys.com

---

From: [email-masked] (Alan Batie)
Date: Mon, 25 Nov 1996 10:55:16 -0800 (PST)

> be unable to bring it up without core dumping...

2.3a1 core dumps quite frequently on BSD/OS 2.1 as well...  gdb shows it
crashing in parse_entry(), so I assume it's getting an advertisement it
doesn't like, but I haven't gotten a chance to get farther than that.

-- 
Alan Batie                     ------        What goes up, must come down.
[email-masked]        \    /        Ask any system administrator.
+1 503-264-8844 (voice)         \  /         --unknown
D0 D2 39 0E 02 34 D6 B4          \/          5A 41 21 8F 23 5F 08 9D

---

From: Bill Fenner <[email-masked]>
Date: Mon, 25 Nov 1996 15:11:41 PST

In message <[email-masked]>you write:
>2.3a1 core dumps quite frequently on BSD/OS 2.1 as well...

How often is "quite frequently"?  I've had a 2.3a1 running on FreeBSD 
2.2-ALPHA for a day now, with no signs of a crash...

I didn't reply to the original message since I don't run 4.1.4, but I've also 
got a 2.3a1 running on SunOS 4.1.3_U1 which has been up for 6 days.

  Bill

---

From: [email-masked] (Alan Batie)
Date: Mon, 25 Nov 1996 15:40:31 -0800 (PST)

> How often is "quite frequently"?  I've had a 2.3a1 running on FreeBSD 

Well, I restarted it this morning around 10:30am or so, and it core dumped
at 2:50pm; this is about typical, though when I first compiled it, I had
trouble getting it to even start:

Core was generated by `sdr'.
Program terminated with signal 11, Segmentation fault.
#0  0x18f519 in vfprintf ()
(gdb) where
#0  0x18f519 in vfprintf ()
#1  0x41a3 in parse_entry (advertid=0x0, data=0x1a25c4 "v=0", length=0, 
    src=3234242981, hfrom=3234242981, sd_addr=0x1ef5c0 "224.2.127.254", 
    sd_port=9875, t=848959583, trust=0x2486 "\004\220j\001hÀc\031", 
    recvkey=0xefbfda68 "") at ../src/sd_listen.c:981
#2  0x316f in recv_packets (fd=0x5) at ../src/sd_listen.c:663
#3  0x107a79 in FindVariable ()
#4  0x1185ce in Tcl_LoadCmd ()
#5  0x11877d in Tcl_LoadCmd ()
#6  0x2d9b in main (argc=1, argv=0xefbfdbf0) at ../src/sd_listen.c:480

---

From: Mark Handley<[email-masked]>
Date: Tue, 26 Nov 96 08:54:48 -0500

>#1  0x41a3 in parse_entry (advertid=3D0x0, data=3D0x1a25c4 "v=3D0", lengt=
>h=3D0,=20
>    src=3D3234242981, hfrom=3D3234242981, sd_addr=3D0x1ef5c0 "224.2.127.2=
>54",=20
>    sd_port=3D9875, t=3D848959583, trust=3D0x2486 "\004\220j\001h=C0c\031=
>",=20
>    recvkey=3D0xefbfda68 "") at ../src/sd_listen.c:981

I don't have a proper debug environment yet since moving from UCL, but
just checking the source I can see that this isn't an unmodified sdr
2.3a1 because line 981 of sd_listen.c is a goto in an error condition,
and your sdr is crashing in vfprintf.

I'm guessing, but perhaps someone's added some debug code to the
version you're running, and that it's that debug code that's broken?

Sorry - I can't help!  I suggest you contact the person that built the
BSDI version of sdr you're running.

Mark

---

From: [email-masked] (Alan Batie)
Date: Tue, 26 Nov 1996 10:26:45 -0800 (PST)

> BSDI version of sdr you're running.

That's me; I added some print statements in an initial attempt to debug it.
I'll send you separate mail, as I doubt the whole list wants it debugged
here.