Ask Your Question

Segmentation fault (core dumped)

asked 2020-11-24 11:02:54 +0000

Anatoliy.Kransov gravatar image

updated 2020-11-24 14:28:26 +0000

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

edit retag flag offensive close merge delete


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.

grahamb gravatar imagegrahamb ( 2020-11-24 15:06:27 +0000 )edit

3 Answers

Sort by ยป oldest newest most voted

answered 2020-11-24 20:10:15 +0000

Guy Harris gravatar image

"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."

edit flag offensive delete link more


Thanks Guy! The best answer here. Ok, I've opened an issue on this failure.

Igor Ivanov gravatar imageIgor Ivanov ( 2020-11-25 09:06:50 +0000 )edit

answered 2020-11-24 11:18:00 +0000

grahamb gravatar image

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.

edit flag offensive delete link more


"free -h" shows 88 Gbyte "free" memory. Not enough for opening 17 GB pcap file?

Igor Ivanov gravatar imageIgor Ivanov ( 2020-11-24 16:18:30 +0000 )edit

Apparently not. Try splitting the file.

grahamb gravatar imagegrahamb ( 2020-11-24 16:27:20 +0000 )edit

Then how much memory will be enough? Or what file size is maximum to open in wireshark?

Splitting is just workaround.

Igor Ivanov gravatar imageIgor Ivanov ( 2020-11-24 16:39:28 +0000 )edit

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.

grahamb gravatar imagegrahamb ( 2020-11-24 16:52:29 +0000 )edit

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?

grahamb gravatar imagegrahamb ( 2020-11-24 16:54:53 +0000 )edit

answered 2020-11-24 11:20:43 +0000

Jaap gravatar image

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.

edit flag offensive delete link more


i have 660 GB ram it's small ?

Anatoliy.Kransov gravatar imageAnatoliy.Kransov ( 2020-11-24 14:14:31 +0000 )edit

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.

Jaap gravatar imageJaap ( 2020-11-24 16:41:32 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-11-24 11:02:54 +0000

Seen: 2,700 times

Last updated: Nov 24 '20