> "Magnus Hagander" <mha@sollentuna.net> writes:
> > What we get is Integer Overflow, on the instruction "idiv
> esi" in postgres!int4div+0x1f. (Per windows debugger.) Same
> does not happen on Linux.
>
> > Tom - hints? ;-) Any idea why this happens on win32 but not linux?
>
> Perhaps there's some process-wide setting that enables or
> disables that?
>
> It seems fairly inconsistent to have a machine trap on divide
> overflow when it doesn't on any other integer overflow, so
> I'd rather turn it off than work around it.
Been doing some more research on this one. Seems that since this is a
hardware exception, there is no way to ignore it :-( What you can do is
create a structured exception filter that will get called, and can
detect it. At this point, you can "do your magic" and then have the
processor re-execute the instruction that failed - with any registers
modified per your preference.
So what we'd do in this case is, from what I can tell, to manipulate EIP
to make it point past the exception itself and then return
EXCEPTION_CONTINUE_EXECUTION.
However, this seems like a lot more of a kludge than putting in a check
in the code. And we'd need to know it's *always* safe to advance EIP
once on integer overflows, which I certainly can't speak for :-)
(If we just say continue execution, the program gets stuck in an
infinite loop because the exception just happens over and over again -
no surprise there)
So given that, I think I'm for putting in the check in the code.
As a sidenote, I noticed I never followed through on an old discussion
about crashing. Right now, when a postgres backend crashes it pops up a
GUI window to let the user know so. Only when the user has dismissed
this window does the postmaster notice. Attached patch changes this so
we don't provide GUI notification on crash, but instead just crashes and
let the postmaster deal with it.
//Magnus
