ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 7960] Buildbot crash output: fuzz-2012-11-06-1334.pcap

Date: Mon, 03 Dec 2012 16:01:03 +0000

changed bug 7960

What Removed Added
Status CONFIRMED RESOLVED
Resolution --- FIXED

Comment # 5 on bug 7960 from
(In reply to comment #4)
> (In reply to comment #3)
> 
> > Martin, if you can still reproduce it, maybe TVB_SET_ADDRESS() should call
> > tvb_get_ptr() and set the data field in 2 steps.  (I would think that an
> > exception being thrown in a function whose return value is being stored in a
> > variable would mean that the variable is not modified, but what do I know?)
> 
> your change fixed the issue for me. I don't see the unhandled exception any
> more.

Great, thanks for verifying.

> I don't quite understand the underlying problem, though.
> Apparently, SET_ADDRESS(..., tvb_get_ptr()) causes problems when
> tvb_get_ptr() throws an exception. Moving it anywhere outside the macro
> parameters, either befor the macro or inside it, fixes things. Is the return
> value undefined if tvb_get_ptr() throws an exception?

Well, my *expectation* is that if an exception is thrown the variable would not
be modified; that's because I'd expect the assembly to look something like:

call tvb_get_ptr()
store the result in the appropriate place

Of course if an exception is thrown the 2nd instruction would never be
executed.  But whether it's /required/ to be like this I don't know...


You are receiving this mail because:
  • You are watching all bug changes.