[haiku-bugs] Re: [Haiku] #6736: [Network stack] crashes while trying to quit Fuppes

#6736: [Network stack] crashes while trying to quit Fuppes
----------------------------------------+----------------------------
   Reporter:  diver                     |      Owner:  axeld
       Type:  bug                       |     Status:  reopened
   Priority:  normal                    |  Milestone:  R1
  Component:  Network & Internet/Stack  |    Version:  R1/Development
 Resolution:                            |   Keywords:  multicast
 Blocked By:                            |   Blocking:
Has a Patch:  0                         |   Platform:  All
----------------------------------------+----------------------------
Changes (by mmlr):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 At least screenshots 1 and 4 look exactly like the ones that happened here
 due to the FreeBSD compatibility layer issue fixed in r42904. So there
 seem to be two separate bugs here, one of which was fixed, the other still
 open. Even though it'd be nicer to have separate bug reports for each,
 let's just reopen this one.

 Replying to [comment:6 siarzhuk]:
 > Looks like it is just partially fixed. Unfortunately it is still
 observed with my sis19x network driver on revisions after r42899. Typical
 stack crawl is looking like one in attached fuppes_kdl2.png (JoinGroup +
 0x00f6). One time it was crashed in the same place as shown in
 fuppes_kdl3.png (Clear() + 0x0060). Note that sis19x is '''native'''
 driver so freebsd compat layer could not be taken into account - so r42899
 changes are unrelated in this exact case.

 I see. The FreeBSD ones still use the same upper layers though, so it's
 entirely possible to run into that issue with a FreeBSD driver as well. In
 my limited test case I was doing something unrelated, so I didn't stress
 test the multicast mechanism after the fix.

 > Are there any suggestion to trace or debug?

 Adding/enabling tracing to see what's really going on would make sense. I
 can take another look of course to see if I can spot anything when using
 the indicated software. I've used my own SSDP implementation and did kill
 the app always, so it's possible that, if the software mentioned does do a
 proper cleanup on getting the signal, different code paths were used.

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/6736#comment:8>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: