Wireshark-dev: Re: [Wireshark-dev] Debugging an assertion failure
From: "Maynard, Chris" <Christopher.Maynard@xxxxxxx>
Date: Fri, 14 Apr 2017 13:39:23 +0000

Shouldn’t that read, “Crash if there isn’t”?

 

In case the offending character isn’t obvious, maybe it’s an em dash that looks like a hyphen?  Certain software has the annoying habit of automatically converting ‘-‘ to ‘‘, for example; maybe that happened to you Paul?

cat dashes.txt

1: -

2: –

 

hexdump -C dashes.txt

00000000  31 3a 20 2d 20 0a 32 3a  20 e2 80 93 0a           |1: - .2: ....|

0000000d

 

Just a guess.

- Chris

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Michael Mann
Sent: Friday, April 14, 2017 7:57 AM
To: wireshark-dev@xxxxxxxxxxxxx
Subject: Re: [Wireshark-dev] Debugging an assertion failure

 

There were a lot of suggestions on how to break on the failure point (which I can't help with), but if you just go to the line it complains about (it's slightly different in the master branch I have), you come up with:

 

* Make sure that only lower-case ASCII letters, numbers,

* underscores, hyphens, and dots appear in the name.

*

* Crash if there is, as that's an error in the code;

* you can make the title a nice string with capitalization,

* white space, punctuation, etc., but the name can be used

* on the command line, and shouldn't require quoting,

* shifting, etc.

 

So I would say the issue is that you have a invalid character in your preference name or description.

 

 

-----Original Message-----
From: Paul Offord <Paul.Offord@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Apr 14, 2017 6:42 am
Subject: [Wireshark-dev] Debugging an assertion failure

Hi,

 

I need some advice.  I’m debugging a problem with a dissector I’ve written.  Tshark fails with:

… \epan\prefs.c:414:prefs_register_module_or_subtree: assertion failed: (g_ascii_islower(c) || g_ascii_isdigit(c) || c == '_' || c == '-' || c == '.')

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

If I remove the dissector the problem goes away and so I’m sure it’s the cause.

 

Even though I can recreate the problem in a debug build under VS 2013 it doesn’t catch the exception.  I just see the above text flash by in the output command box.  How can I cause execution to break when it throws the exception?

 

Thanks and regards…Paul



CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information.  This message is intended solely for the use of the addressee.  If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited.