Re: Debugging an assertion failure

["Maynard, Chris" <Christopher.Maynard () IGT com>]

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 () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Michael Mann
Sent: Friday, April 14, 2017 7:57 AM
To: wireshark-dev () wireshark org
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 () advance7 com<mailto:Paul.Offord () advance7 com>>
To: Developer support list for Wireshark <wireshark-dev () wireshark org<mailto:wireshark-dev () wireshark org>>
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.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe