Good afternoon! Faced a problem, when opening a file over 17 gb, I get a core dump error The problem repeats on Windows and Centos Wireshark versions are newest everywhere! "Segmentation fault (core dumped)" g_ascii_strcasecmp: assertion 's1 != NULL' failed Segmentation fault (core dumped) I have 660 GB RAM and 72 core for this task
Unless your providing terabytes of RAM this dissection won't fit. You can chop up the capture file in sizeable parts, of let's say 500MiB, using editcap and see what happens then.
i have 660 GB ram it's small ?
No, that's not small. That's an amount I've never seen used for Wireshark before. So we're venturing in uncharted territory, where new bugs may appear that never have been hit before. A detailed issue report including stack trace would be the least that's needed to get an investigation started into possibly buggy code. And then testing of any solutions would be virtually impossible due to limited resources available to the average developer.
You've probably run out of memory, see the wiki page for this with some suggestions on how to tackle it.
For your case, splitting the capture into smaller files is likely the solution.
"free -h" shows 88 Gbyte "free" memory. Not enough for opening 17 GB pcap file?
Apparently not. Try splitting the file.
Then how much memory will be enough? Or what file size is maximum to open in wireshark?
Splitting is just workaround.
There's no definitive answer, it depends on the protocols in the capture and whether there is keying material to decrypt etc. and various other dissector options.
Maybe a better question is what are you trying to do with a 17GB capture? Surely you aren't visually inspecting it, so what result do you want?
"Segmentation fault (core dumped)" g_ascii_strcasecmp: assertion 's1 != NULL'
That does not appear, at first glance, to be one of the sort of crashes that would occur from running out of memory. Most of the memory allocation in the Wireshark code is done with GLib's memory allocation wrappers, which, by default, crash on failure, rather than returning NULL, so those would be crashes in the memory allocator, not g_ascii_strcasecmp() crashes.
This is probably some other routine that can return NULL, such as a lookup routine, where the caller isn't checking for an error.
The fact that it happened with a very large file may just be due to a large file having more packets and thus being more likely to have a packet in which something that "can't happen" or "shouldn't happen" nevertheless happens.
Unfortunately, there are several calls to g_ascii_strcasecm() in Wireshark (many text-based protocols have case-insensitive keywords, and case-insensitive comparisons must be done in a locale-independent fashion, to, for example, avoid having "I" and "i" being treated as different), so, as @Jaap said, "A detailed issue report including stack trace would be the least that's needed to get an investigation started into possibly buggy code."
Thanks Guy! The best answer here. Ok, I've opened an issue on this failure.
Comments
Have you tried splitting the capture? Note that dissection expands on the original capture size as packets are decompressed, decrypted and associations and references between packets are built.