Yes, the "guilty party" was the UI freeing/allocating prefs.gui_font_name with
g_ scoped memory when I was trying to get preferences to use wmem_epan_scoped
memory. I'm a little annoyed at myself for not catching that earlier when I
initially converted the "global preference strings" to use wmem scoped memory.
And I thought my previous bisecting would have also flushed it out.
The two things that were useful to me in the investigation:1. -k option for
pytest to run individual tests. That let me pick one of the 3 failing test to
add as much debug as I wanted to Wireshark and not upset the rest of the suite
(i.e. brute force)2. A small "debug log text file" created within main() of
Wireshark. I probably should have used ws_log functionality, but I knew the
debug I added was going to be temporary anyway (with a lot of "did I get here?"
type statements)
I appreciate the help.
On Friday, January 9, 2026 at 02:57:18 PM EST, Eugène Adell
<[email protected]> wrote:
Hi Michael,
I see the MR has moved since, but I was spending time investigating.
At the end I isolated this part which brings an invalid pointer. If
that helps.
regards
Eugène
1435 * If the value is a null pointer, make it a copy of a null
1436 * string, otherwise make it a copy of the value.
1437 */
1438 tmp = *var;
1439 if (*var == NULL) {
1442 *var = wmem_strdup(pref->scope, "");
1443 } else {
1446 *var = wmem_strdup(pref->scope, *var);
1447 }
Le ven. 9 janv. 2026 à 13:49, Michael Mann via Wireshark-dev
<[email protected]> a écrit :
>
> Capture permissions shouldn't be the issue as its running with admin
> privileges, and the tests pass without my changes. The question is more
> about trying to break down the Python tests so I can run them "in isolation",
> preferably through MSVC.
>
>
> On Friday, January 9, 2026 at 04:34:40 AM EST, Eugène Adell
> <[email protected]> wrote:
>
>
> Hello Michael,
>
> as these tests are related to capturing, are the prerequisites for
> capturing with a non-admin user met ? Some hints are given on the wiki
> : https://wiki.wireshark.org/CaptureSetup/CapturePrivileges
>
> best regards
> Eugène
>
> Le ven. 9 janv. 2026 à 05:16, Michael Mann via Wireshark-dev
> <[email protected]> a écrit :
> >
> > I'm working on MR 23103 (not really relevant/required for my questions) and
> > it's failing some of the automated Python test suite, specifically:
> > test_wireshark_capture_10_packets_to_file
> > test_wireshark_capture_from_stdin
> > test_wireshark_capture_snapshot_len
> >
> > I've bisected the patch down to the smallest change possible of the
> > pass/fail criteria, but I'm still not having any luck identifying the
> > (code) problem. The failures are "heap corruption", which I can see as a
> > possibility given my code changes, but a call stack when it happens would
> > go a long way to helping me hunt down the source of problem.
> > Many times previously I could look at what the suite test is doing and run
> > the individual capture file in Wireshark/tshark to find the source of my
> > problem. But it looks like these tests are piping "static" capture files
> > through to Wireshark (so they look like captured packets). Am I reading
> > that correctly? (my Python skills are beginner level). Any tips to
> > potentially hook this up to a debugger (MSVC on Windows) or generating a
> > crash report? Or steps to reproduce the test in MSVC (without Python)?
> >
> > _______________________________________________
> > Wireshark-dev mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> _______________________________________________
> Wireshark-dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Wireshark-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
