Wireshark-bugs: [Wireshark-bugs] [Bug 7060] Buildbot crash output: fuzz-2012-04-10-21548.pcap
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7060
--- Comment #6 from Evan Huus <eapache@xxxxxxxxx> 2012-05-20 05:26:14 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > The pcap file doesn't cause a crash on my svn build.
>
> I reverted extra scrubing code in r42013.
Ah, the context of those memory-scrubbing commits makes everything make sense
:)
> (In reply to comment #4)
> > Should this be closed as fixed?
>
> It *can* be closed, but you'll get extra points if you propose
> "acceptable" solution for fixing "global variables problem" [1]
> and attach sample patch for this bug (patch at least need to remove problematic
> variables, check attachment #8185 [details]) :-)
For the cases in this bug at least, why can't we use p_add_proto_data and
p_get_proto_data with ep_ allocated data? Unless I'm missing something, they
are only being used in packet scope?
For the general case where globals are used to store (private) data across
multiple packets that aren't necessarily in the same conversation, I would
suggest adding an f_add_proto_data and f_get_proto_data that have file scope
instead of packet scope. That nicely mirrors ep/se (in fact, they should
perhaps be renamed to ep_add_proto_data, se_add_proto_data, etc)? Off the top
of my head the only case that doesn't cover is when a global is declared in a
header file to share data between dissectors, and we already have packet_info,
however awfully messy, for that.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
