Bug 828 – PacketSocket::Close does not unregister protocol handler

Bug 828 - PacketSocket::Close does not unregister protocol handler


Summary:	PacketSocket::Close does not unregister protocol handler

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	network
Version:	ns-3.7
Hardware:	All All

Importance:	P5 normal
Assigned To:	Mathieu Lacage

URL:	http://groups.google.com.au/group/ns-...
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2010-03-02 19:52 EST by Quincy Tse
Modified:	2010-05-30 23:55 EDT (History)
CC List:	3 users (show)

See Also:

Attachments
Proposed patch. (511 bytes, patch) 2010-03-02 19:56 EST, Quincy Tse	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Quincy Tse 2010-03-02 19:52:18 EST

It seems that PacketSocket::Close doesn't work properly for me - I 
kept getting segfaults when packets are attempted to be forwarded 
through closed sockets that had already had the memory deallocated.

During a typical lifetime of a PacketSocket, the protocal handler is registered in the function PacketSocket::DoBind, executed on transiting from STATE_OPEN to STATE_BOUND. When transiting from STATE_BOUND to STATE_CONNECTED, the protocol remains registered. In order to clean up properly, the PacketSocket should unregister the protocol handler on close for the transitions STATE_BOUND->STATE_CLOSED and STATE_CONNECTED->STATE_CLOSED.

Platform and version: NS-3.7 on Linux 2.6.31-14 (amd64), gcc 4.4.1

Have not developed test code to reproduce the segfault.

Comment 1 Quincy Tse 2010-03-02 19:56:48 EST

Created attachment 774 [details]
Proposed patch.

Comment 2 Quincy Tse 2010-03-02 20:00:59 EST

Possibly related #649, #650

Comment 3 Quincy Tse 2010-05-23 21:49:54 EDT

Patch not yet applied to ns-3-dev or ns-3.8.

Comment 4 Tom Henderson 2010-05-24 09:24:40 EDT

I'll apply this in a day or so after testing, but just cc'ing ns-bugs in the meantime in case anyone has a comment.

Comment 5 Tom Henderson 2010-05-30 23:55:29 EDT

changeset:  7476f746ba5d