Actually, this was a mistake on my management of the dissection pointer.
 Problem resolved.

On Wed, Aug 31, 2011 at 4:34 PM, George Nychis <[email protected]> wrote:

> Hi all,
>
> I have spent a good amount of time porting and cross-compiling libwireshark
> for Android.  My goal is to allow applications to import the library, read
> packets from an interface, and use libwireshark to dissect them.
>
> For the most part, things are working.  I am able to pull packets off an
> interface, create a pcap packet header, and then pass the pcap packet header
> and data to libwireshark.  I can dissect the packet, pull fields of
> interest, etc.  Hopefully when I am done with this, it will be useful to
> others.
>
> I have native C calls which wrap calls in libwireshark to do the
> dissection, and cleanup the dissection.  The dissection seems to go OK,
> however I am getting segfaults trying to properly clean up the dissection
> (free the tree, memory, etc...).  I do not know if this is related to an
> improper dissection, or an improper cleanup.  Sorry if any my terminology is
> not right here, I am learning libwireshark as I go.
>
> First, I have a native C function for dissection: int dissectPacket(char
> *pHeader, char *pData, int encap).  The pcap packet header is passed with
> the packet data and encapsulation type.  The return value is a pointer to
> a write_field_data_t structure, which is created through the dissection.  By
> returning this pointer (which I will later clean up), I allow multiple
> queries on the dissection tree (e.g., getField(dissectionPtr,
> "wlan_mgt.ssid")).  Here is the code for dissectPacket:
> http://pastebin.com/3Ussc4pP
>
> My attempt to cleanup the dissection (by passing the pointer returned by
> dissectPacket()) is relatively simple:
> http://pastebin.com/HuFRCFCP
>
> However, I am consistently segfaulting in the cleanup process.  By running
> GDB over ADB on Android, I am able to get the stack trace (as well as debug
> symbols in my libwireshark):
> #0  free_data_sources (pinfo=0x3040208) at packet.c:245
> #1  0x845d13f0 in epan_dissect_cleanup (edt=0x3040200) at epan.c:210
> #2  0x80d0326a in dissectCleanup (ptr=7944464) at
> /Users/gnychis/Documents/workspace/CoexiSyst/jni/libwireshark/wireshark_helper.c:294
> #3  0x80d03226 in Java_com_gnychis_coexisyst_Packet_dissectCleanup
> (env=0x11e7a0, thiz=0x447a9db8, ptr=7944464) at
> /Users/gnychis/Documents/workspace/CoexiSyst/jni/libwireshark/wireshark_helper.c:282
>
> Because my line numbers may not match up with the most current version of
> wireshark:
>
> packet.c:245 - if (pinfo->data_src) {
> epan.c:210 - free_data_sources(&edt->pi);
>
> So, I suspect that &edt->pi is NULL.
>
> Referencing my dissection code, I call epan_dissect_init() on line 29.
>  Therefore, I assumed I needed a related call to epan_dissect_cleanup() just
> from looking through how tshark uses the dissection API.
>
> In the end, I am not sure if my fault is in dissection or if it is in
> cleanup.  Does anyone have any insight on this?  I would sincerely
> appreciate it!
>
> Thanks,
> George
>
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to