Invisible nous apporta ses lumieres en ce 2007/11/08 04:34:
> ...I'm beginning to think POV-Ray attracts crazy people... o_O
Not at all! Just peoples that are more curious than the norm ;) thus, good 
learners and thinkerers. Probably, also, who have an IQ higher than average.

-- 
Alain
-------------------------------------------------
Tricks and treachery are the practice of fools, that don't have brains enough to 
be honest.
Benjamin Franklin

Post a reply to this message

On Fri, 09 Nov 2007 18:59:50 -0500, Alain wrote:


> There are times when you can't do a stack backtrace because the stack
> have been corrupted. Something like a bad vector that send you to a bit
> of code that call a subprocess, pushing the return address on the stack,
> and the code pointed to ask tou to jump the another subprocess, whitch
> is itself. Infinite loop causing a stack overflow, and in some cases,
> the stack cycling pointer cycling back to zero. Or you enter a loop that
> pop data out of the stack until there is no more data to retreive, and
> the stack pointer jump to the largest value it can contain. There are
> times when the crash can cause corruption far outside the area that a
> process is allowed to access.

Absolutely this can happen.  In my experience, it's not terribly common, 
but sure, ESP and EBP can contain invalid values which can make it ugly 
or impossible to diagnose.  These situations are the exception (pun not 
intended) rather than the rule.

>> I watched one engineer do live debugging of a client issue on a Windows
>> system; watching someone use a tool like that who knows what they're
>> doing is a very interesting thing, because they can pull information
>> about what's going on at any given point in the process.  Doing it live
>> or doing it from a core file is pretty similar, except that with a core
>> file the system isn't changing; it's actually the *easier* way to
>> debug, because you're working from a snapshot of a program at a point
>> in time instead of watching things change.
> Easier to look at a snapshot than to the changes. The snapshot is
> frozen. If you try to look as it changes, it's usualy to fast.

Yes, a snapshot is easier.  Fortunately, if you're doing "live" 
debugging, you do have the opportunity to halt things and look at the 
state, and then single step over or through functions.  That doesn't help 
if the issue is a timing issue, but those can be the most difficult to 
nail down.

Having access at the kernel level, you can do all kinds of neat things.

Jim

Post a reply to this message

Invisible wrote:
> Now, how about that Windoze habit of saying "The program has experienced 
> an error and will be shut down. Do you want to send debugging 
> information?" What do you estimate the chances are that *anybody* will 
> do anything at all with the data thus sent? ;-)

I have, on occasion, sent in reports like that, and had Microsoft reply 
with how to fix it. So obviously someone was paying attention to it.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Orchid XP v7 wrote:
> That's impressive. Usually these things work by inserting software 
> interrupts into the code. (Or just software enumation of machine state...)

Nowadays, actually, they tend to play with the memory map to cause traps 
to occur where you want to see things. Breakpoint when you write a 
variable? Map the page the variable is in as read-only, then when the 
trap happens, see if the instruction was pointing to the variable.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Most other languages don't futz with the class of the object while it's 
>> being constructed, so it doesn't really come up, I guess. One of the 
>> costs of multiple inheritance as implemented by C++?
> 
>   I don't understand what multiple inheritance has to do with this.

The need for multiple vtables in the final class.  Well, it's not 
specifically multiple inheritance, but rather the fact that vtables are 
indexed with fixed indecies for virtual functions, which means you have 
to modify the base pointer if you have more than one parent class.

If you only have one chain of inheritance, then the virtual functions in 
child classes can always come after the virtual functions in parent 
classes without conflict. If you have multiple inheritance, two parent 
classes might assign the same index to two different virtual functions, 
and something that inherits from both needs to disambiguate.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Warp wrote:
>   It would be difficult for the compiler to follow how the functions are
> being called (and, in fact, it's impossible for it to know if the pure
> virtual function actually gets called in the general case).

Especially if that function is already compiled and in a library 
somewhere. :-)

>   The problem with calling a pure virtual function in the base class
> constructor is that the derived class has yet not been initialized and
> thus calling a derived class function implementation could cause undefined
> behavior because it's not constructed.

You mean, undefined behavior as opposed to a core dump? ;-)

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> >   The problem with calling a pure virtual function in the base class
> > constructor is that the derived class has yet not been initialized and
> > thus calling a derived class function implementation could cause undefined
> > behavior because it's not constructed.

> You mean, undefined behavior as opposed to a core dump? ;-)

  Yes, undefined behavior. It could work like a charm, or it could cause
a segmentation fault. (The latter may easily happen if, for example, the
function in the derived class accesses eg. a string, which obviously has
not yet been initialized and contains garbage.)

-- 
                                                          - Warp

Post a reply to this message

Alain wrote:
> Invisible nous apporta ses lumieres en ce 2007/11/08 04:34:
>> ...I'm beginning to think POV-Ray attracts crazy people... o_O
> Not at all! Just peoples that are more curious than the norm ;) thus, 
> good learners and thinkerers. Probably, also, who have an IQ higher than 
> average.

Well, maybe you guys do. Mine is only 103... :-(

Post a reply to this message

Invisible wrote:
> Alain wrote:
>> Invisible nous apporta ses lumieres en ce 2007/11/08 04:34:
>>> ...I'm beginning to think POV-Ray attracts crazy people... o_O
>> Not at all! Just peoples that are more curious than the norm ;) thus, 
>> good learners and thinkerers. Probably, also, who have an IQ higher 
>> than average.
> 
> Well, maybe you guys do. Mine is only 103... :-(
The average is 100 by definition. So, what are you trying to prove? 
Perhaps that your math skills have declined since taking that test and 
that you should be below 100 now? Some complicated sort of self 
fulfilling estimate?

Post a reply to this message

Darren New wrote:
> Orchid XP v7 wrote:
>> That's impressive. Usually these things work by inserting software 
>> interrupts into the code. (Or just software enumation of machine 
>> state...)
> 
> Nowadays, actually, they tend to play with the memory map to cause traps 
> to occur where you want to see things. Breakpoint when you write a 
> variable? Map the page the variable is in as read-only, then when the 
> trap happens, see if the instruction was pointing to the variable.

Interesting. I thought (in C) all variables exist on the machine stack?

Post a reply to this message