Crashing a program 
Author Message
 Crashing a program

Yes I like to know how to "crash" a program.

It works like follows:

I have a program which calls exec another program:
{$M $400,0,0}

swapvectors;
exec('other.exe','');
swapvectors;

Right, Now this program is only allowed to run for a given amount of time.

So I install a timer interrupt:

procedure handler; interrupt;
begin
 inc(counter);
end;

setintvec($8,addr(handler));

Know say I like the time to be 5 secs I have the if statment:
 if counter > 90 then
   begin
     {end running program}
   end;

My question is, how do I make this other program bail out?

thanks in advance
Heinrich



Wed, 18 Jun 1902 08:00:00 GMT  
 Crashing a program


Quote:

>Yes I like to know how to "crash" a program.

>It works like follows:

>I have a program which calls exec another program:
>{$M $400,0,0}
>My question is, how do I make this other program bail out?

If the EXECed program is your own, then you can use (I think) one of the
intercommunication areas, or part of a known-unused interrupt vector,
and make your outer program set a bit there when time is up; your inner
program can monitor this bit, and go away in good order when requested.

There may be other methods.

--

  Prof Timo Salmi's Usenet Q&A <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqn.zip>
  Other TS FAQs : http://www.uwasa.fi/~ts/http/  tsfaq.html  quotmarg.html .
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.



Wed, 18 Jun 1902 08:00:00 GMT  
 Crashing a program
To crash a program, just run it under Windows, and wait (it won't be too
long, don't worry)...


Wed, 18 Jun 1902 08:00:00 GMT  
 Crashing a program
Hi,

Quote:

> To crash a program, just run it under Windows, and wait (it won't be too
> long, don't worry)...

Hey, it *should* be remarked that when a program crashes under Windows,
it is definitely the programmer's fault. If Windows crashes because of
this, or behaves strangely, it's Windows' fault.

 - Sebastian



Wed, 18 Jun 1902 08:00:00 GMT  
 Crashing a program

Quote:



>>Yes I like to know how to "crash" a program.

>>It works like follows:

>>I have a program which calls exec another program:
>>{$M $400,0,0}

>>My question is, how do I make this other program bail out?

>If the EXECed program is your own, then you can use (I think) one of the
>intercommunication areas, or part of a known-unused interrupt vector,

Yes, Inter Process Communication Area - 16 bytes at $0000:$04F0 though
best to save the previous values before using it.

Another, and probably rather better thought is to set up a variable in
the data area of the program doing the timing and pass the address to
the called program during the EXEC.

In fact, if it is his own program then he might as well put the code
in the called program unless it is to run for variable times with each
execution.

If it's not his own program he is calling, then I can't think offhand of
an easy way to do it - it would probably have to be something like:

1. Write own Exec procedure that allocates memory and stores PSP and  
   called program memory addresses/size;
   plus storing CS:IP of next calling program instruction, BP, SS:SP
   before allowing it to execute;
2. Hook into Int $08 and monitor time;
3. Hook into Int $13 and Int $21 (plus others ?) & set up semaphores;
4. Execute child program;
5. If time up, then allow Int $08 to complete then at the interrupt end,
   Check if a semaphore is set - if so then don't do anything; If not:
6. Deallocate memory and reset register stack to next instruction in the
   calling program from stored values.
7. IRET

He'd also need, for neatness, to have saved, then restore the calling
program screen if either program outputs to the screen.

Messy and would possibly leave child programs that handle data files
with corrupt data in them unless file open / file close was monitored
in the calling program and caches flushed before closing them.

The question might well be asked of the original question: why ?

--
Information on Newsgroup posted weekly on Sunday - read before writing!
Contains links to    |  http://www.pedt.serve.net.uk/faq/clpb-faq.txt
helpful information  |  http://www.merlyn.demon.co.uk/clpb-faq.txt
and some guidelines  |  ftp://garbo.uwasa.fi/pc/doc-net/faqclpb.zip



Wed, 18 Jun 1902 08:00:00 GMT  
 Crashing a program

Quote:

>Hi,


>> To crash a program, just run it under Windows, and wait (it won't be too
>> long, don't worry)...

>Hey, it *should* be remarked that when a program crashes under Windows,
>it is definitely the programmer's fault. If Windows crashes because of
>this, or behaves strangely, it's Windows' fault.

> - Sebastian

I will agree it is the programmers fault if by that you mean one of
the programmers in Redmond.  

Bob



Wed, 18 Jun 1902 08:00:00 GMT  
 Crashing a program
Hi,

Quote:

>>Hey, it *should* be remarked that when a program crashes under Windows,
>>it is definitely the programmer's fault. If Windows crashes because of
>>this, or behaves strangely, it's Windows' fault.

<snip>

Quote:
> I will agree it is the programmers fault if by that you mean one of
> the programmers in Redmond.  

Interesting question: How many of the GPFs and Page Faults that make
life under Windows so interesting, stem from bugs in Microsoft code?
Surely a lot of them are just bugs in programs that would have crashed
under others systems as well.

The truly devastating thing esp. with 16-bit Windows, as I understand
it, was that the operating system itself was not sufficiently protected
from programs messing with pointers, so the whole system would crash.
GPFs are probably the most common error under OS/2, coyly called
"SYS1345" or something to that direction, but at least the system lives
on.

 - Sebastian



Wed, 18 Jun 1902 08:00:00 GMT  
 Crashing a program

Quote:
> > I will agree it is the programmers fault if by that you mean one of
> > the programmers in Redmond.

> Interesting question: How many of the GPFs and Page Faults that make
> life under Windows so interesting, stem from bugs in Microsoft code?
> Surely a lot of them are just bugs in programs that would have crashed
> under others systems as well.

Most of them, on slow machines :-)

If I pump the load, msgsrv32 GPF's on any pentium till 166 with win98,
and
hard reset is the only way out.

(any 4 heavy processor using programs will do, but
real-time queue ones (like WinAmp with certain parameters) count double)

But I don't download crappy applications everyday, so GPF's have to come
from normal, standard apps, or FPC.

I take FPC as example, but any compiler or other non heavily hardware
interfacing app could be substituted.

FPC (or my programs compiled with it) crashed windows numerous times,
but hardly ever crashed linux. The OS should, and is capable of
terminating
such an app. FreeBSD never got trashed, but doesn't have 1% of the
exposure of the other two targets.

Also the FPC IDE can crash Windows without a fault. Just use a *lot* of
mem (say over 64MB) with the IDE on a p133 with winamp playing
and kablam.

Under Linux, the system slows down terribly, the harddisk sounds if can
jump out of the tower any minute, but it doesn't crash :-)

So don't tell me it's the APPS fault....................



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Using ShChangeNotify crashes my program?

2. If one DBE application crashes, they all crash...

3. Program crashing out of graphics mode under Windows NT 4.0

4. Program crash on TTable.FindKey

5. Weird program crashes using BDE 5.0

6. Crashing program when accessing file on server

7. Why does my program crash?

8. Program crashes while calling a DLL

9. Program crashes on other computers????

10. Database program in Delphi 2.0 crash help

11. MSSQL7-ODBC-BDE Crashes on TQuery.Free

12. MSSQL7-ODBC-BDE Crashes on TQuery.Close

 

 
Powered by phpBB® Forum Software