Wireshark-bugs: [Wireshark-bugs] [Bug 7960] Buildbot crash output: fuzz-2012-11-06-1334.pcap
Jeff Morriss
changed
bug 7960
| What |
Removed |
Added |
| Status |
CONFIRMED
|
RESOLVED
|
| Resolution |
---
|
FIXED
|
Comment # 5
on bug 7960
from Jeff Morriss
(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.
