https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16561
--- Comment #7 from Guy Harris <ghar...@sonic.net> ---
(In reply to stdedos+wireshark from comment #5)
> (In reply to Guy Harris from comment #3)
> > I couldn't reproduce this on macOS (whose ability to show stack traces for
> > crashes beats Windows's all hollow).
>
> Well, it's not my option to use Windows; but it is the system under test
I wasn't dismissing the bug, I was just noting that it might be Windows-only,
so anybody who wants to look at it might not be able to try it on macOS or
Linux or....
> > So presumably it doesn't crash if you drop the same file on it after it's
> > *finished* initialization.
>
> Yes it works.
>
> > What happens if you drop a smaller file on it while it's initializing?
>
> Same issue. Have at this one instead (attached)
So it's a "drop a capture, of any size, on Wireshark while it's initializing"
problem, not a "drop a *large* capture on Wireshark" issue.
Perhaps the code path for drag-and-drop on Windows doesn't defer opening and
reading the file until after the initialization is complete; if the main
window's dropEvent() method can be called while Wireshark is still
initializing, it needs to queue up the list of files so that they can be opened
when initialization is done.
--
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
