Wireshark mailing list archives
Re: se_alloc() GSList segfault woes
From: Jaap Keuter <jaap.keuter () xs4all nl>
Date: Tue, 20 Apr 2010 16:23:15 +0200
Hi, Maybe rethink the problem in light of binary trees, see doc/README.binarytrees. Thanks, Jaap On Tue, 20 Apr 2010 07:46:12 -0400, "Jeremy O'Brien" <obrien654j () gmail com> wrote:
Hello everyone, I am using a static GSList to record some data about packets I've seen so that I can look up said info later. I've defined a custom callback for my g_slist_find_custom function that does NULL checking of the data that gets passed to it. I am allocating items that I append to the GSList with se_alloc(). The items are all very small. Essentially the problem is that wireshark segfaults whenever I open a capture file that uses this GSList, and then reopen it or another one that uses the GSList too. I believe I know why this is happening from my extraneous testing. It seems that the GSList (which gets created with the first call to g_slist_append()) sticks around after I open a new file, and my functions that add things to and search the list are crashing because they end up trying to access invalid memory (memory that was free'd do to my use of se_alloc for the items in the GSList). I feel that I could solve this by calling a g_slist_free() on my GSList (and set it to NULL) whenever my dissector opens a new file. I am not sure how to go about doing this however. I was trying to find a way to do the call on the first packet wireshark sees, so long as pinfo->fd->flags.visisted is not set, but I couldn't find a way to verify that this was the first packet dissected. To summarize what I believe is happening: I have a GSList whose elements are allocated with se_alloc(). The elements are (probably) being freed when I open a new file. The GSList still has pointers to these (now freed) elements, so my find callback segfaults when it tries to access the (nonexistant) data. What should I do to resolve this/make it better???? Any ideas or smacks upside the head for bad programming will be graciously accepted. Thank you for your time, Jeremy
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- se_alloc() GSList segfault woes Jeremy O'Brien (Apr 20)
- Re: se_alloc() GSList segfault woes Jaap Keuter (Apr 20)
- Re: se_alloc() GSList segfault woes Jeremy O'Brien (Apr 20)
- Re: se_alloc() GSList segfault woes Jaap Keuter (Apr 20)
- Re: se_alloc() GSList segfault woes Jeremy O'Brien (Apr 20)
- Re: se_alloc() GSList segfault woes Jeff Morriss (Apr 20)
- Re: se_alloc() GSList segfault woes Jeremy O'Brien (Apr 20)
- Re: se_alloc() GSList segfault woes Martin Mathieson (Apr 20)
- Re: se_alloc() GSList segfault woes Martin Mathieson (Apr 20)
- Re: se_alloc() GSList segfault woes Jaap Keuter (Apr 20)