Hi,
Well, you said it yourself: "probably unique" != "unique", so you'll have to be
the judge on that.
Thanks,
Jaap
Jeremy O'Brien wrote:
Thank you very much for your suggestion. It works great! Now for a subquestion.
I am keeping track of mac addresses, which are obviously 6 bytes. The
key is 4 bytes. I've been keying on the last four bytes of the mac
address, because these will probably be unique across a session. Do
you think this will be enough to have unique keys, or should I use
se_tree_*_array functions instead?
Thank you!
Jeremy
On Tue, Apr 20, 2010 at 10:23, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
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@xxxxxxxxx> 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