If this is undefined then it's a hell of a good one
Bart Kowalski
not just the program, but the entire system.
#include <stdio.h>
int main(void)
{
while(1)
printf("\t\t\b\b\b\b\b\b");
return 0;
}
I was just wondering if this is possibly UB or is it just a particularly stupid
bug in Windows NT (or maybe a special "feature" :)).
Bart.
Mark A. Odell
news:3bd6ca7e$0$2695$45be...@newscene.com:
I'm betting that NT is doing what you ask, "Run my program with preference,
even if I use a console driver most of the time, hence starving the rest of
the system." I'm not sure this is really a C question though.
--
- Mark A. Odell
- Embedded Firmware Design, Inc.
- http://www.embeddedfw.com
osmium
Nothing that comes out of Redmond could possibly surprise me.
It encouraged me (I've been thinking about doing this) to write a file with
Word forWindows with the content "hello world". It is 11,264 bytes.
What does UB stand for?
Bart Kowalski
news:Xns91446745DC091lk...@130.133.1.4...
> "Bart Kowalski" <m...@nospam.com> wrote in
> news:3bd6ca7e$0$2695$45be...@newscene.com:
>
> > Believe it or not the following simple program crashes Windows NT &
> > 2000. Yes, not just the program, but the entire system.
> >
> > #include <stdio.h>
> >
> > int main(void)
> > {
> > while(1)
> > printf("\t\t\b\b\b\b\b\b");
> >
> > return 0;
> > }
> >
> > I was just wondering if this is possibly UB or is it just a
> > particularly stupid bug in Windows NT (or maybe a special "feature"
> > :)).
>
> I'm betting that NT is doing what you ask, "Run my program with preference,
> even if I use a console driver most of the time, hence starving the rest of
> the system." I'm not sure this is really a C question though.
The thing is that it is only this particular sequence that crashes the system (a
series of tabs followed by a series of backspaces). I was wondering if perhaps
there was something special about outputting backspaces that I didn't know
about.
Bart.
Mark A. Odell
Quite honestly, it could actually be a bug in the video driver. I'll try
this program here and email my results if you wish. Have you tried this on
another computer/video card?
Ryan Hennessy
What do you except the behaviour to be? Should it loop around until the end of
time? If language alone doesn't categorize your program as UB, common sense
should. If you are going to continue to write programs like that expecting them
_not_ to break your computer, at least move to a system with some process control
(read: kill -9).
Ryan.
Hong Ooi
Oddly enough, it doesn't do anything to Win98.
Hong "crash test dummies R us" Ooi
--
Hong Ooi | Centre for Maths and its Applications
hong...@maths.anu.edu.au | Australian National University
Ph: (02) 6267 4140 | ACT 0200 Australia
rihad
I too ran it under Windows 2000 - hell the machine was kind enough to
do a cold reboot. Then I could even hear the harddisks spinning :)
My curiosity peaked, so I tried it under BeOS and FreeBSD - they were
all cool and I was able to kill the offender with ^C.
BTW, "you should flush the ouput if you want the user to see anything"
:)))
>Bart.
>
>
--
rihad
Dan Pop
Count it as Windows bug. The behaviour of your program is unspecified,
not undefined.
\b (backspace) Moves the active position to the previous
position on the current line. If the active position is
at the initial position of a line, the behavior is
unspecified.
\t (horizontal tab) Moves the active position to the next
horizontal tabulation position on the current line. If
the active position is at or past the last defined
horizontal tabulation position, the behavior is
unspecified.
It is not clear (to me) if the following environmental limit is relevant
in this case:
Environmental limits
[#7] An implementation shall support text files with lines
containing at least 254 characters, including the
terminating new-line character.
I'm not sure that an interactive device can count as a text file.
If it does, then your program does exceed an environmental limit,
so a case could be made for undefined behaviour.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
pete
It runs under MSVC++ V5.0.
Whether or not the last line of a text stream requires
a terminating new-line character, is implementation-defined.
I don't know if that has anything to do with your problem.
--
pete
Richard Heathfield
All I can find in the Standard on this issue is:
5.2.2 Character display semantics
\b (backspace) Moves the active position to the previous position on the
current line. If the active position is at the initial position of a
line, the behavior of the display device is unspecified.
So I guess that whether the behaviour is unspecified depends on your tab
settings.
Anyway, I wouldn't necessarily blame the crash on the program. Not in
this case, anyway.
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Tim Hagan
>
> Nothing that comes out of Redmond could possibly surprise me.
>
> It encouraged me (I've been thinking about doing this) to write a file with
> Word forWindows with the content "hello world". It is 11,264 bytes.
MS Word97 makes it 19,456 bytes. Bloatware at its finest.
> What does UB stand for?
Undefined Behavior
--
Tim Hagan
Zoran Cutura
My guess is _undefined behavior_.
--
Z (Zoran....@daimlerchrysler.com)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
pete
Could the problem be that stdout never gets flushed?
--
pete
osmium
news:3BD6D19B...@alcatel.com...
A serious operating system should have a real-time mode where some
application can take over the system. An ordinary C program should not
accidentally be executed in such a mode. The program should be given some
time slice periodically until hell freezes over. That is what should have
happened.
I don't know that Microsoft sells Windows with the notion that it is a
serious operating system, I certainly hope not. But Windows NT *is* sold
with that pretense. I have read (I hope it's not true) that the US
government lists Windows NT as an approved GSA purchase.
Joona I Palaste
> osmium wrote:
>>
>> Nothing that comes out of Redmond could possibly surprise me.
>>
>> It encouraged me (I've been thinking about doing this) to write a file with
>> Word forWindows with the content "hello world". It is 11,264 bytes.
> MS Word97 makes it 19,456 bytes. Bloatware at its finest.
As an experiment, I wrote a document containing *nothing at all* in
MS Word 2000. Result: 19 kilobytes. If this isn't bloatware, what is?
>> What does UB stand for?
> Undefined Behavior
Ugly Bloat, more like. =)
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates
Tyler Larson
> #include <stdio.h>
> return 0;
> }
Throw out any ideas you might have of a buffer overflow or anything
of that nature. I did some tests and came to the following
*very disturbing* conclusion:
This code will NOT reboot the machine:
#include <stdio.h>
int main(void)
{
while (1)
printf("\t\b");
return 0;
}
However, this code WILL reboot the machine:
#include <stdio.h>
int main(void)
{
printf("\t\b\b");
return 0;
}
That's right, it only has to execute *once*. There's only one
logical explanation as far as I can tell. I'm running a piece of
sh*t operating system.
It's nice to know that this is the software that's running so
many poor saps' fileservers, webservers, mail servers, etc.
There should be an CERT advisory put out warning people to never
run Microsoft software on mission-critical systems.
--
Tyler Larson | http://www.tlarson.com | news(a)tlarson.com
A journey of a thousand miles begins with a cash advance.
rihad
wrote:
>Tim Hagan <timothy...@boeing.com> scribbled the following:
>> osmium wrote:
>>>
>>> Nothing that comes out of Redmond could possibly surprise me.
>>>
>>> It encouraged me (I've been thinking about doing this) to write a file with
>>> Word forWindows with the content "hello world". It is 11,264 bytes.
>
>> MS Word97 makes it 19,456 bytes. Bloatware at its finest.
>
>As an experiment, I wrote a document containing *nothing at all* in
>MS Word 2000. Result: 19 kilobytes. If this isn't bloatware, what is?
>
>>> What does UB stand for?
>
>> Undefined Behavior
>
>Ugly Bloat, more like. =)
Hey, comon, guys! This is none better than judging a compiler by the
size of the hello world executable :) For example, mingw is reported
to produce tiny helloworlds (around 3kb),as compared to what msvc does
(16k).
But, the other day I built vim version 6.0 - 700k with msvc and around
900 with mingw. Go figure.*
[*] I used the of the box makefiles
--
rihad
Hong Ooi
wrote:
>Tim Hagan <timothy...@boeing.com> scribbled the following:
>> osmium wrote:
>>>
>>> Nothing that comes out of Redmond could possibly surprise me.
>>>
>>> It encouraged me (I've been thinking about doing this) to write a file with
>>> Word forWindows with the content "hello world". It is 11,264 bytes.
>
>> MS Word97 makes it 19,456 bytes. Bloatware at its finest.
>
>As an experiment, I wrote a document containing *nothing at all* in
>MS Word 2000. Result: 19 kilobytes. If this isn't bloatware, what is?
Well, I just took a 200+ page Word document I had lying around and
converted it to PostScript. In so doing, it went from 1.25MB to 8.96MB. As
a PDF, it was 1.45MB. If I wanted just plain text, it would be ~900K.
Hong "haven't tried running it through indent yet" Ooi
osmium
> Well, I just took a 200+ page Word document I had lying around and
> converted it to PostScript. In so doing, it went from 1.25MB to 8.96MB. As
> a PDF, it was 1.45MB. If I wanted just plain text, it would be ~900K.
So tell me. Was Stalin worse than Hitler? Or vice versa?
Tyler Larson
> However, this code WILL reboot the machine:
> #include <stdio.h>
> int main(void)
> {
> printf("\t\b\b");
> return 0;
> }
I lied-- this code doesn't ALWAYS reboot the machine, you need
to repace the string "\t\b\b" with "\t\b\b " to make it work.
You need to print a tab, backspace twice, then print any character.
That last character, which is printed off the edge of the screen,
triggers the reboot.
I was running under visual studio which prints out
"Press any key to continue" after each execution when running from
within the IDE, so the code "worked" when Visual Studio printed out
it's little message, but failed to reboot when run on its own.
The following updated code will *always* reboot your high-quality
server machine with that $1000 MS operating system you put on it:
#include <stdio.h>
int main(void)
{
printf("\t\b\b ");
return 0;
}
--
Tyler Larson | http://www.tlarson.com | news(a)tlarson.com
A hermit is a deserter from the army of humanity.
Bart Kowalski
Well, YMMV, but a program that loops forever is not usually very dangerous.
Windows NT does provide fairly decent process control so I don't see what the
rant above is all about.
Bart.
Morris Dovey
> The following updated code will *always* reboot your high-quality
> server machine with that $1000 MS operating system you put on it:
>
> #include <stdio.h>
> int main(void)
> {
> printf("\t\b\b ");
> return 0;
> }
It's a FEATURE. (Thanks, Bill!)
--
Morris Dovey
West Des Moines, Iowa USA
Bart Kowalski
news:0hldttg2sd6tvkd21...@4ax.com...
> On 24 Oct 2001 09:07:18 -0500, "Bart Kowalski" <m...@nospam.com> wrote:
>
> >Believe it or not the following simple program crashes Windows NT & 2000.
Yes,
> >not just the program, but the entire system.
> >
> >#include <stdio.h>
> >
> >int main(void)
> >{
> > while(1)
> > printf("\t\t\b\b\b\b\b\b");
> >
> > return 0;
> >}
> >
> >I was just wondering if this is possibly UB or is it just a particularly
stupid
> >bug in Windows NT (or maybe a special "feature" :)).
>
> Oddly enough, it doesn't do anything to Win98.
Doesn't seem odd to me since Windows NT and Windows 98 work in a completely
different way. Bugs don't usually jump from one program to the other. :)
Bart.
Bart Kowalski
Sorry, I preffer not receiving personal e-mail. The program was tested on
several different machines. Actually, this program was posted in
comp.ms-windows.programmer.win32 and I thought I would ask about it here as I
was just curious to know what the C experts had to say.
Bart.
Hong Ooi
Well, it all depends. Stalin has a Base Attack Bonus of at least +15, which
grants him two additional attacks at +10 and +5. He can also rage three
times per day, increasing his Strength and Constitution scores by +4 each
which because he is 15th level gives him at least 30 additional hit points
(although these are not temporary hit points, and go away at the end of the
rage). He also has Weapon Specialisation with his +4 greataxe, and on a
critical hit can deal up to (12+9+4+2)*3 == 81(!!) points of damage on a
single blow. Obviously Stalin is not someone you want to tangle with on a
regular basis. On the other hand, Hitler has the Spring Attack and Superior
Expertise feats, which aren't to be underestimated either. The latter in
particular allows him to increase his Armor Class by up to +15, making him
that much a harder target. With his Boots of Striding and Springing, he can
also move like lightning all over the battlefield, allowing him to strike
and retreat out of range of his opponents with impunity. He can't take
quite as much damage as Stalin, but as long as he isn't totally reckless,
he could probably last just as long. In terms of resistances, Stalin's high
Constitution grants him a better Fortitude save bonus than Hitler, but
that's counterbalanced by Hitler's Dexterity, which improves his Reflex
saves. Unfortunately, neither one would have a particularly high Will save
bonus, but that's par for the course for mad dictators.
Hope this helps!
Hong "casting Power Word, Plonk" Ooi
Mark A. Odell
>> Quite honestly, it could actually be a bug in the video driver. I'll
>> try this program here and email my results if you wish. Have you tried
>> this on another computer/video card?
>
> Sorry, I preffer not receiving personal e-mail. The program was tested
> on several different machines. Actually, this program was posted in
> comp.ms-windows.programmer.win32 and I thought I would ask about it
> here as I was just curious to know what the C experts had to say.
Sure, okay. Anyhow, this program does nothing to Windows NT v4.0 SP6a. I
ran it for 15 seconds. Should I wait longer? I used CTRL-c to kill it. I
used the cmd.exe shell to execute it. I did use Cygwin's gcc to build it,
however.
Bart Kowalski
On my machine it rebooted immediately. But the behavior doesn't seem to be
consistent between different systems. See the tread "Bug which crash Windows
2000 and XP" in comp.os.ms-windows.programmer.win32 (sorry about the wrong name
I gave previously).
Bart.
Ben Pfaff
> What does UB stand for?
Undefined Behavior.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Ben Pfaff
> On 24 Oct 2001 09:07:18 -0500, "Bart Kowalski" <m...@nospam.com> wrote:
>
> >#include <stdio.h>
> >
> >int main(void)
> >{
> > while(1)
> > printf("\t\t\b\b\b\b\b\b");
> >
> > return 0;
> >}
>
> BTW, "you should flush the ouput if you want the user to see anything"
That's not really necessary in this case. Writing an infinite
series of output sequences to a stream with a finite buffer (if
it is buffered at all) will always cause flushing automatically
at some point.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms
Ben Pfaff
> The thing is that it is only this particular sequence that crashes the system (a
> series of tabs followed by a series of backspaces). I was wondering if perhaps
> there was something special about outputting backspaces that I didn't know
> about.
The behavior of backspace at the beginning of a line is
unspecified:
\b (backspace) Moves the active position to the previous
position on the current line. If the active position is at
the initial position of a line, the behavior of the display
device is unspecified.
I suppose that Microsoft could specify it as crashing the system,
but that's hardly a robust choice and not really in the spirit of
the Standard.
willem veenhoven
> > anything"
>
> That's not really necessary in this case. Writing an infinite
> series of output sequences to a stream with a finite buffer (if
> it is buffered at all) will always cause flushing automatically
> at some point.
Methinks it's a bug in the buffered IO functions anyhow. At least,
I could not reproduce this sure_to_crash feature by using write()
to dump the same string to [_]fileno(stdout).
Didn't I warn you that the implementations of the fopen-functions
on the platform I usually work on are buggy by default ;-)
willem
Mark A. Odell
>> Sure, okay. Anyhow, this program does nothing to Windows NT v4.0 SP6a.
>> I ran it for 15 seconds. Should I wait longer? I used CTRL-c to kill
>> it. I used the cmd.exe shell to execute it. I did use Cygwin's gcc to
>> build it, however.
>
> On my machine it rebooted immediately. But the behavior doesn't seem to
> be consistent between different systems. See the tread "Bug which crash
> Windows 2000 and XP" in comp.os.ms-windows.programmer.win32 (sorry
> about the wrong name I gave previously).
Hence I believe this to be a video device driver issue.
David Anderson
> MS Word97 makes it 19,456 bytes. Bloatware at its finest.
Really make you think... in assembly you can get to that in a couple 10s of
bytes... :-)
David Anderson
David Anderson
>with that pretense. I have read (I hope it's not true) that the US
>government lists Windows NT as an approved GSA purchase.
Windows NT is certified C2 security, sufficient for transmitting military
importance data... But it only has C2 certification if it is NOT
networked... Must have been the Redmond village idiot who thought that one
up...
David Anderson
Dann Corbit
news:3bd713fe$0$92341$45be...@newscene.com...
It does nothing on any of my NT or Win2k machines. I tried this simplified
one that is supposed to create the same effect:
#include <stdio.h>
int main(void)
{
printf("\t\b\b ");
return 0;
}
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm
Daniel Dekany
"osmium" <r124...@mediaone.net> wrote in message
news:MECB7.15455$CN5.1...@typhoon.mn.mediaone.net...
<snip>
> I don't know that Microsoft sells Windows with the notion that it is a
> serious operating system, I certainly hope not. But Windows NT *is* sold
> with that pretense. I have read (I hope it's not true) that the US
> government lists Windows NT as an approved GSA purchase.
Well, I have seen an educational film about the communication and strategy
computer control system of USA Air Forces. It is supposedly designed to
coordinate the attack in "real time". I was socked to see when the computers
of ground control operators booting: Windows NT 4.0! I hope it was just to
deceive the audience... or else I'm not surpied at the hit of the Chinese
embassy. :)
Regards,
Daniel Dekany
Gordon Burditt
Bug-free, bloat-free code would certainly surprise me.
>>> It encouraged me (I've been thinking about doing this) to write a file with
>>> Word forWindows with the content "hello world". It is 11,264 bytes.
>
>> MS Word97 makes it 19,456 bytes. Bloatware at its finest.
>
>As an experiment, I wrote a document containing *nothing at all* in
>MS Word 2000. Result: 19 kilobytes. If this isn't bloatware, what is?
They must be using a high-power compression algorithm to compress
all those macro viruses. Those are required to satisy the
virus industry. (No, I don't mean the anti-virus industry).
Gordon L. Burditt
Mark McIntyre
<david.anderson@NO_SPAM.calixo.net> wrote:
>
>>with that pretense. I have read (I hope it's not true) that the US
>>government lists Windows NT as an approved GSA purchase.
>
>
>Windows NT is certified C2 security, sufficient for transmitting military
>importance data... But it only has C2 certification if it is NOT
>networked...
ISTR you also have to take out the floppy drive, and remove the
keyboard.
>Must have been the Redmond village idiot who thought that one up...
actually I think it was the Langley village idiot...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Dan Pop
>"Bart Kowalski" <m...@nospam.com> writes:
>
>> The thing is that it is only this particular sequence that crashes the system (a
>> series of tabs followed by a series of backspaces). I was wondering if perhaps
>> there was something special about outputting backspaces that I didn't know
>> about.
>
>The behavior of backspace at the beginning of a line is
>unspecified:
>
> \b (backspace) Moves the active position to the previous
> position on the current line. If the active position is at
> the initial position of a line, the behavior of the display
> device is unspecified.
>
>I suppose that Microsoft could specify it as crashing the system,
>but that's hardly a robust choice and not really in the spirit of
>the Standard.
In this case, the C implementation would have a conformance problem:
unlike undefined behaviour, unspecified behaviour has no licence to result
in program abnormal termination. A program invoking unspecified
behaviour is still a correct C program and the rest of the guarantees
provided by the C standard apply to it. There is no room for nasal
demons or disk reformatting here.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Dan Pop
>Dan Pop wrote:
>>
>> It is not clear (to me) if the following environmental limit is relevant
>> in this case:
>>
>> Environmental limits
>>
>> [#7] An implementation shall support text files with lines
>> containing at least 254 characters, including the
>> terminating new-line character.
>>
>> I'm not sure that an interactive device can count as a text file.
>> If it does, then your program does exceed an environmental limit,
>> so a case could be made for undefined behaviour.
>
>Could the problem be that stdout never gets flushed?
The stdio output routines are supposed to automatically flush when the
associated buffer is full. You can see that with the following trivial
program:
#include <stdio.h>
int main()
{
while (1) putchar('a');
return 0; /* to keep the compiler happy */
}
Even if stdout is line buffered on your system (it normally is, when
connected to a terminal), if this program doesn't cause your system to
crash (for the above-mentioned reason), you'll probably see its output
on the screen.
Mark McIntyre
>In <87vgh4q...@pfaff.stanford.edu> Ben Pfaff <b...@cs.stanford.edu> writes:
>
>>The behavior of backspace at the beginning of a line is
>>unspecified:
>>
>> \b (backspace) Moves the active position to the previous
>> position on the current line. If the active position is at
>> the initial position of a line, the behavior of the display
>> device is unspecified.
>>
>>I suppose that Microsoft could specify it as crashing the system,
>>but that's hardly a robust choice and not really in the spirit of
>>the Standard.
>
>In this case, the C implementation would have a conformance problem:
>unlike undefined behaviour, unspecified behaviour has no licence to result
>in program abnormal termination.
I think that in this instance, the Standard is probably worded
wrongly. According to the glossary,
"unspecified behavior
behavior where this International Standard provides two or more
possibilities and imposes no further requirements on which is chosen
in any instance"
I don't see the Standard providing _any_ possibilities here. So is
this not in fact undefined behaviour?
>A program invoking unspecified
>behaviour is still a correct C program and the rest of the guarantees
>provided by the C standard apply to it. There is no room for nasal
>demons or disk reformatting here.
Agreed, since normally the Standard would provide choices.
I don't see the Standard saying
"\b = backspace.... If the active position is at the initial position
of a line, the behavior of the display device is unspecified but may
include doing nothing, or setting fire to your socks, or some other
implementation defined behaviour"
Mark McIntyre
>In <3BD6E9...@mindspring.com> pete <pfi...@mindspring.com> writes:
>>
>>Could the problem be that stdout never gets flushed?
>
>The stdio output routines are supposed to automatically flush when the
>associated buffer is full.
The problem may be the reverse - each \t inserts a tab chars into hte
buffer, and each \b removes one. So we're walking backwards off the
buffer array, into buffer underflow as it were. That _would_ be UB.
Mark McIntyre
>"Mark A. Odell" <ma...@embeddedfw.com> wrote in message
>news:Xns914495BB2C422lk...@130.133.1.4...
>> Anyhow, this program does nothing to Windows NT v4.0 SP6a. I
>> ran it for 15 seconds. Should I wait longer? I used CTRL-c to kill it. I
>> used the cmd.exe shell to execute it. I did use Cygwin's gcc to build it,
>> however.
>
>On my machine it rebooted immediately. But the behavior doesn't seem to be
>consistent between different systems. See the tread "Bug which crash Windows
>2000 and XP" in comp.os.ms-windows.programmer.win32 (sorry about the wrong name
>I gave previously).
I presume you've reported this to Microsoft?
Mark McIntyre
>Bart Kowalski <m...@nospam.com> wrote:
>> Believe it or not the following simple program crashes Windows NT & 2000. Yes,
>> not just the program, but the entire system.
>
>> #include <stdio.h>
>> int main(void)
>> {
>> while(1)
>> printf("\t\t\b\b\b\b\b\b");
>> return 0;
>> }
>
>> I was just wondering if this is possibly UB or is it just a particularly stupid
>> bug in Windows NT (or maybe a special "feature" :)).
It crashed my two different Win2K machines (laptop and desktop). So
throw out ideas about video cards. This looks to me like a resource
problem in Windows.
>Throw out any ideas you might have of a buffer overflow or anything
>of that nature. I did some tests and came to the following
>*very disturbing* conclusion:
>
>This code will NOT reboot the machine:
in fact neither of your pieces of code affected either of my machines.
You may have discovered a DIFFERENT bug...
>There should be an CERT advisory put out warning people to never
>run Microsoft software on mission-critical systems.
I'm not sure thats a conclusion you can draw from this....
Zarchery
> Believe it or not the following simple program crashes Windows NT & 2000. Yes,
> not just the program, but the entire system.
>
> #include <stdio.h>
>
> int main(void)
> {
> while(1)
> printf("\t\t\b\b\b\b\b\b");
>
> return 0;
> }
>
> I was just wondering if this is possibly UB or is it just a particularly stupid
> bug in Windows NT (or maybe a special "feature" :)).
Well that certainly is interesting. I'll have to try it out next time
I'm at school.
And how did this message leak over into rec.games.frp.dnd?
-----Zarchery-----
Bart Kowalski
news:v7ietts3nv95bapmt...@4ax.com...
> On 24 Oct 2001 14:21:10 -0500, "Bart Kowalski" <m...@nospam.com> wrote:
>
> I presume you've reported this to Microsoft?
Not yet, but I will.
Bart.
Bart Kowalski
> "Bart Kowalski" <m...@nospam.com> wrote in
> news:3bd713fe$0$92341$45be...@newscene.com:
>
> >> Sure, okay. Anyhow, this program does nothing to Windows NT v4.0 SP6a.
> >> I ran it for 15 seconds. Should I wait longer? I used CTRL-c to kill
> >> it. I used the cmd.exe shell to execute it. I did use Cygwin's gcc to
> >> build it, however.
> >
> > On my machine it rebooted immediately. But the behavior doesn't seem to
> > be consistent between different systems. See the tread "Bug which crash
> > Windows 2000 and XP" in comp.os.ms-windows.programmer.win32 (sorry
> > about the wrong name I gave previously).
>
> Hence I believe this to be a video device driver issue.
Well, many people seem to have the same problem on different machines. Here are
the systems that I tested it on:
- Win2K Pro, Intel PII, MSVC 6.0: reboot
- WinNT 4.0 SP6, Intel PII, MSVC 6.0: BSOD + reboot after 2 sec
- Win98 SE, AMD K6, MSVC 6.0: nothing
- Win2K Pro, Intel PIII, MSVC 6.0: reboot
I haven't checked what graphics cards the systems have, but I'm pretty sure that
they are not the same, since they were bought at different times from different
places.
Maybe it's a bug in the C run-time of MSVC on Windows NT, but that's just
regular user-mode code so I don't see how it could crash the system.
Bart.
Mike Wahler
Mark McIntyre wrote in message ...
>On 24 Oct 2001 22:27:46 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
>>In <3BD6E9...@mindspring.com> pete <pfi...@mindspring.com> writes:
>>>
>>>Could the problem be that stdout never gets flushed?
>>
>>The stdio output routines are supposed to automatically flush when the
>>associated buffer is full.
>
>The problem may be the reverse - each \t inserts a tab chars into hte
>buffer, and each \b removes one.
No it does not. The character with value '\b' is
inserted into the stream. How the particular hardware
device (e.g. a terminal) responds to this character is
what's unspecified by the standard.
In memory, '\b' is a character just like any other.
-Mike
Kevin D. Quitt
No crashes with debug or release, with or without the loop. gcc likewise
no problem, but you could see some cursor blur. Only unusual thing was
Control-C from the VC++ produced executables shows the ^C at column 50 of
the same line as the command.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91351-4454 96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list
osmium
> Believe it or not the following simple program crashes Windows NT & 2000.
Yes,
> not just the program, but the entire system.
>
> #include <stdio.h>
>
> int main(void)
> {
> while(1)
> printf("\t\t\b\b\b\b\b\b");
>
> return 0;
> }
>
> I was just wondering if this is possibly UB or is it just a particularly
stupid
> bug in Windows NT (or maybe a special "feature" :)).
I don't know where to attach this so I will post at the head. I sense a
disturbing trend. A trend to discuss what the offending program did. A
time sharing computer system should not crash no matter what a user program
did or didn't do. One should be able to throw assembly language programs
written by a random number generator at it all day and all night and it
should not crash. The mechanism that caused the problem is of no interest
whatsoever except to the people assigned to fix the problem.
I sense this digression in several distinct threads which is why I thread it
here.
Bart Kowalski
It's not as simple as this. Some people have suggested driver problems, others
CRT bugs. The point is that an operating system is made up of many different
parts which don't necessarily know about each other. The OS itself is there only
to coordinate those parts, but it is not responsible for everything that they
do.
Many people don't understand that a great number of Windows bugs are actually
caused by third-party software, not by Windows itself. That said, however, I
think the present case is really a Windows bug.
Bart.
Gordon Burditt
>stupid
>> bug in Windows NT (or maybe a special "feature" :)).
>
>I don't know where to attach this so I will post at the head. I sense a
>disturbing trend. A trend to discuss what the offending program did. A
>time sharing computer system should not crash no matter what a user program
>did or didn't do.
You are correct, but good luck trying to get Microsoft to fix it,
especially when such a fix might prove to be incompatible with
existing viruses and worms.
>One should be able to throw assembly language programs
>written by a random number generator at it all day and all night and it
>should not crash.
Well, there are many operating systems where an ordinary user should
not be able to crash it, but an administrator does have the privileges
to do something stupid enough to crash the system (consider the
equivalent of the Unix "rm -rf /").
>The mechanism that caused the problem is of no interest
>whatsoever except to the people assigned to fix the problem.
No, it is also of great interest to people attempting to work around
the problem. It can save a lot of middle-of-the-night calls to
the on-call Microsoft Certified Reboot Engineer if you can avoid
outputting the offending sequence of characters to the console in
the first place on your employer's dedicated database and web
servers.
Of course, in the case of Microsoft operating systems, you have to
assume that the primary purpose of running applications is to do
something other than provide parameters for the Blue Screen of
Death (or, for those with the patches, the Red Screen of Death).
I believe Microsoft will disagree with this.
Incidentally, in the continuing discussion of crashes-my-system,
doesn't-touch-mine, oh-yes-it-does, it might be useful to provide
details like what version of NT you are using and what video driver
is in use.
Gordon L. Burditt
osmium
news:3bd782ca$0$85506$45be...@newscene.com...
Well can someone find out what lash-up approved by the GSA is? They (the
government) aren't buying parts at Fry Electronics and putting them together
are they? Aren't things like graphics cards given a seal of approval by
Microsoft? Remember when Win 95 came out. To get the Windows logo a
program was supposed to have an uninstall program for one thing.
pete
Thank you.
--
pete
John Bode
> Bart Kowalski <m...@nospam.com> wrote:
> > Believe it or not the following simple program crashes Windows NT & 2000. Yes,
> > not just the program, but the entire system.
>
> > #include <stdio.h>
>
> > int main(void)
> > {
> > while(1)
> > printf("\t\t\b\b\b\b\b\b");
>
> > return 0;
> > }
>
> > I was just wondering if this is possibly UB or is it just a particularly stupid
> > bug in Windows NT (or maybe a special "feature" :)).
>
> of that nature. I did some tests and came to the following
> *very disturbing* conclusion:
>
> This code will NOT reboot the machine:
>
> int main(void)
> {
> while (1)
> printf("\t\b");
>
> return 0;
> }
>
>
> However, this code WILL reboot the machine:
>
> #include <stdio.h>
> int main(void)
> {
> printf("\t\b\b");
> return 0;
> }
>
> That's right, it only has to execute *once*. There's only one
> logical explanation as far as I can tell. I'm running a piece of
> sh*t operating system.
>
> It's nice to know that this is the software that's running so
> many poor saps' fileservers, webservers, mail servers, etc.
> There should be an CERT advisory put out warning people to never
> run Microsoft software on mission-critical systems.
Some data points (Win2K):
If built with gcc in the Cygwin shell, the above code will not cause a
reboot, whether it is invoked at a command line (Cygwin or DOS shells)
or launched from Explorer.
If built with MSVC, it will not cause a reboot if invoked from a
Cygwin shell, but will cause a reboot if invoked from a DOS shell or
launched from Explorer.
I'm trying to check the knowledge base at support.microsoft.com to see
if there are any articles on this, but that server seems to be down.
Dan Pop
>On 24 Oct 2001 22:27:46 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
>>In <3BD6E9...@mindspring.com> pete <pfi...@mindspring.com> writes:
>>>
>>>Could the problem be that stdout never gets flushed?
>>
>>The stdio output routines are supposed to automatically flush when the
>>associated buffer is full.
>
>The problem may be the reverse - each \t inserts a tab chars into hte
>buffer, and each \b removes one.
Chapter and verse, please.
>So we're walking backwards off the
>buffer array, into buffer underflow as it were. That _would_ be UB.
Sheer nonsense!
Hong Ooi
>
>I'm trying to check the knowledge base at support.microsoft.com to see
>if there are any articles on this, but that server seems to be down.
Obviously the MS sysadmins were testing this too. ;)
--
Hong Ooi | Centre for Maths and its Applications
hong...@maths.anu.edu.au | Australian National University
Ph: (02) 6267 4140 | ACT 0200 Australia
Mark McIntyre
<mkwa...@ix.netcom.com> wrote:
>
>Mark McIntyre wrote in message ...
>>On 24 Oct 2001 22:27:46 GMT, Dan...@cern.ch (Dan Pop) wrote:
>>
>>>In <3BD6E9...@mindspring.com> pete <pfi...@mindspring.com> writes:
>>>>
>>>>Could the problem be that stdout never gets flushed?
>>>
>>>The stdio output routines are supposed to automatically flush when the
>>>associated buffer is full.
>>
>>The problem may be the reverse - each \t inserts a tab chars into hte
>>buffer, and each \b removes one.
>
>No it does not. The character with value '\b' is
>inserted into the stream.
you missed my point. As far as the C interface to the standard library
is concerned you're right. But once it goes into that library, we've
no clue what happens. I'm hypothesising that there's a buffer inside
that library which is written to the screen device when flushed,
rather like you or I might manage a line editor. I guess that when we
received \b in a line editor we'd decrement the pointer to the current
line location.
>How the particular hardware
>device (e.g. a terminal) responds to this character is
>what's unspecified by the standard.
Agreed.
Kevin D. Quitt
>Cygwin shell, but will cause a reboot if invoked from a DOS shell or
>launched from Explorer.
Clearly, not enough information is being submitted about the system on
which this is tried, both hardware and DLL versions. It does not crash
any of my NT4 or Win2K boxes under any circumstances.
Daniel Dekany
"John Bode" <john...@my-deja.com> wrote in message
news:43618c0e.01102...@posting.google.com...
The fact that it crashes the system only whith MSVC makes it likely that the
MS implementation of C library calls a Win32 API function with a invalid
parameter value (-> bug in MS C library implementation), and then the system
function behaves badly and corrupts something that cannot be corrupted by
user programms directly (-> Bug in "kernel"). Perhaps I should trace into
the printf and see what actually hapens. Well, I let MS do it... :)
Daniel Dekany
Mark McIntyre
>In <qkjetto1dasvohtbk...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>
>>On 24 Oct 2001 22:27:46 GMT, Dan...@cern.ch (Dan Pop) wrote:
>>
>>>In <3BD6E9...@mindspring.com> pete <pfi...@mindspring.com> writes:
>>>>
>>>>Could the problem be that stdout never gets flushed?
>>>
>>>The stdio output routines are supposed to automatically flush when the
>>>associated buffer is full.
>>
>>The problem may be the reverse - each \t inserts a tab chars into hte
>>buffer, and each \b removes one.
>
>Chapter and verse, please.
See my reply in the other subthread.
>>So we're walking backwards off the
>>buffer array, into buffer underflow as it were. That _would_ be UB.
>
>Sheer nonsense!
What, walking off the start of an array is /not/ UB? Are you out of
your mind?
Tor Rustad
<snip>
> The fact that it crashes the system only whith MSVC makes it likely that
the
> MS implementation of C library calls a Win32 API function with a invalid
> parameter value (-> bug in MS C library implementation), and then the
system
Ohhh..how do you explain that Borland compiler crashed NT/Win2K aswell
compiling/running the code at hand?
--
Tor <torust AT online DOT no>
Lawrence Kirby
...
>>I suppose that Microsoft could specify it as crashing the system,
>>but that's hardly a robust choice and not really in the spirit of
>>the Standard.
>
>In this case, the C implementation would have a conformance problem:
>unlike undefined behaviour, unspecified behaviour has no licence to result
>in program abnormal termination.
The standard requires a conforming C implementation to be able to
translate and execute one program that contains an instance of each
of the minimum translation limits. The implementation can terminate
any other program abnormally at any time. What a conforming implementation
is required to do when executing a program is produce output that
is consistent with the semantic of the abstract machine as far as the
execution proceeds up to program termination initiated by the program code.
> A program invoking unspecified
>behaviour is still a correct C program and the rest of the guarantees
>provided by the C standard apply to it.
Guarantees relating to corerect output apply but only as far as the
program successfully executes.
> There is no room for nasal
>demons or disk reformatting here.
What if stdout is attached to a nasal demon device? C requires that
the execution environment maintains consistency while the program is
executing, but I don't see any guarantees once program execution has
been ceased. That's the realm of broader standards or platform
documentation.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Daniel Dekany
"Tor Rustad" <tor...@online.no.spam> wrote in message
news:q%0C7.1911$kV1....@news1.oke.nextra.no...
Ohhh... If you read back what I have writen: "The fact that it crashes the
system only with MSVC" ...etc. That is, it's new for me that it crashes with
Borland compiler too. Then may "explanation" is not applicabe of course.
Daniel Dekany
Tor Rustad
> system only with MSVC" ...etc. That is, it's new for me that it crashes
with
> Borland compiler too. Then may "explanation" is not applicabe of course.
Such reports has been made over in comp.os.ms-windows.programmer.win32
Dan Pop
>On 25 Oct 2001 13:36:00 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
>>In <qkjetto1dasvohtbk...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>>
>>>On 24 Oct 2001 22:27:46 GMT, Dan...@cern.ch (Dan Pop) wrote:
>>>
>>>>In <3BD6E9...@mindspring.com> pete <pfi...@mindspring.com> writes:
>>>>>
>>>>>Could the problem be that stdout never gets flushed?
>>>>
>>>>The stdio output routines are supposed to automatically flush when the
>>>>associated buffer is full.
>>>
>>>The problem may be the reverse - each \t inserts a tab chars into hte
>>>buffer, and each \b removes one.
>>
>>Chapter and verse, please.
>
>See my reply in the other subthread.
It's plain bullshit.
>>>So we're walking backwards off the
>>>buffer array, into buffer underflow as it were. That _would_ be UB.
>>
>>Sheer nonsense!
>
>What, walking off the start of an array is /not/ UB? Are you out of
>your mind?
You are. Nothing in the posted code results in walking off the start of
an array. Therefore, the posted code can't invoke undefined behaviour for
that particular reason.
If the code invokes undefined behaviour it is because it exceeds an
environmental limit. This is no longer the case for the revised
version, that only outputs a few characters. The only remaining issue
is that the last line of output is not properly terminated. As far as
I know, Windows implementations don't require it to be, so this shouldn't
be a problem, either.
Mark McIntyre
>>>>So we're walking backwards off the
>>>>buffer array, into buffer underflow as it were. That _would_ be UB.
>>>
>>>Sheer nonsense!
>>
>>What, walking off the start of an array is /not/ UB? Are you out of
>>your mind?
>
>You are. Nothing in the posted code results in walking off the start of
>an array.
You _still_ don't see my point.
>Therefore, the posted code can't invoke undefined behaviour for
>that particular reason.
>
>If the code invokes undefined behaviour it is because it exceeds an
>environmental limit.
Thats also possible.
Mark McIntyre
>In <o61htt0iokqtnr2lb...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>
>>On 25 Oct 2001 13:36:00 GMT, Dan...@cern.ch (Dan Pop) wrote:
>>
>>>In <qkjetto1dasvohtbk...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>>>
>>>>The problem may be the reverse - each \t inserts a tab chars into hte
>>>>buffer, and each \b removes one.
>>>
>>>Chapter and verse, please.
>>
>>See my reply in the other subthread.
>
>It's plain bullshit.
Let me refresh for you:
the C library (whose internal workings are not defined by ISO)
receives some characters to put into a buffer before putting them to
stdout.
I hypothesise that in order to efficiently manage that buffer, a \b
results in the last character being removed from the buffer, rather
than sending it to the output device, and relying on hardware
features. Naturally, if you remove the -1th character, you're
accessing memory you don't own. Naturally also there should be some
protection against that, which is missing in the implementation.
This to me seems a possible behaviour of stdout. Show me why its
bullsh*t.
Jeremy Yallop
>> the
>> MS implementation of C library calls a Win32 API function with a invalid
>> parameter value (-> bug in MS C library implementation), and then the
>> system
>
>Ohhh..how do you explain that Borland compiler crashed NT/Win2K aswell
>compiling/running the code at hand?
The code also causes a system reboot when compiled with MinGW.
The equivalent Java program has the same effect, FWIW.
Jeremy.
Imanpreet Singh Arora
> Believe it or not the following simple program crashes Windows NT & 2000. Yes,
> not just the program, but the entire system.
>
> #include <stdio.h>
>
> int main(void)
> {
> while(1)
> printf("\t\t\b\b\b\b\b\b");
>
> return 0;
> }
>
> I was just wondering if this is possibly UB or is it just a particularly stupid
> bug in Windows NT (or maybe a special "feature" :)).
>
>
The thing seems to be very much natural for me because as against the
argument that only the given code would fail I have a disagreement
because
printf (“\t\b\b”); for the equvalent also fails on my both
win me and Win 2000 code gen. By Borland compiler it seems to me that
these systems tend to do some nice calculations on the number of
char’s in the buffer i.e. the systems would tend to calculate
the number of effective positions by which the cursor has to be
shifted from the present position.
Which Is a really intelligent feature if I would be allowed to
express my viewpoint.
The bug I have been really been able to find is in the borland
Compiler or maybe windows because it damaged the complete .c file in
the process of execution. These are the final remains of the file
c0x32.obj+
bug.obj
bug.exe /*This was the name of the file bug.cpp :-) */
/Gn/c/x/ap/Tpe
import32.lib+
cw32.lib
However the code would also fail if the code would be consiting of an
equvialent do while block.
But this is what I say and who am I a stupid little kid. Right!! so
kindly tell me if I am wrong.
P.S I have just joined the thread so probably I am not updated with
most of developments.
Bart Kowalski
stdio code runs in user mode. It's very unlikely that this could possibly crash
the entire system. The bug is most likely at a much lower level.
Bart.
Mark McIntyre
The user portion does, sure. At some point there's a kernel driver
involved, to push data to the H/W. Maybe thats where the buffer is?
>It's very unlikely that this could possibly crash
>the entire system. The bug is most likely at a much lower level.
I agree. That doesn't mean my hypothesis is implausible tho.
Dan Pop
Because your hypothetical implementation doesn't match the specification
from the standard:
\b (backspace) Moves the active position to the previous
position on the current line. If the active position is
at the initial position of a line, the behavior is
unspecified.
Read the last phrase carefully. The behaviour is unspecified, not
undefined.
BTW, the implementation code doesn't invoke undefined behaviour, as you
wrote. Undefined behaviour is something for application code, not for
implementation code. Of course, this doesn't mean that implementation
code can't be buggy, merely that it doesn't make sense to talk about
undefined behaviour in this context. Implementation code contains plenty
of constructs that would invoke undefined behaviour if used in application
code. Their behaviour is well defined, however, because this code is
written by people who know what the compiler does and the code is not
supposed to be compiled by other compilers. Look at the Linux kernel or
glibc. Their documentation specifies not only what compiler has to be
used, but also what version(s) of that compiler. With another compiler
(or the wrong gcc version) the code may not even compile at all.
Likewise, don't expect the Windows implementation code to compile with
anything else than Microsoft compilers.
The problem with your hypothesis is that the bug would be in the
standard library implementation, which runs in userland, so it couldn't
cause the system to crash, it would crash your program only.
The hypothesis of a bug in the console driver code makes a lot more sense,
because this code runs with OS privileges and it can crash the whole
system if it does bad things.
Mike Wahler
Jeremy Yallop wrote in message <9rbddl$sko2g$1...@ID-114079.news.dfncis.de>...
Well, that pretty much seals it. It's not a problem
with a C implementation, but some OS 'internals' botch.
-Mike
Mike Wahler
>
>>In <o61htt0iokqtnr2lb...@4ax.com> Mark McIntyre
<ma...@garthorn.demon.co.uk> writes:
>>
>>>On 25 Oct 2001 13:36:00 GMT, Dan...@cern.ch (Dan Pop) wrote:
>>>
>>>>In <qkjetto1dasvohtbk...@4ax.com> Mark McIntyre
<ma...@garthorn.demon.co.uk> writes:
>>>>
>>>>>The problem may be the reverse - each \t inserts a tab chars into hte
>>>>>buffer, and each \b removes one.
>>>>
>>>>Chapter and verse, please.
>>>
>>>See my reply in the other subthread.
>>
>>It's plain bullshit.
>
>Let me refresh for you:
>the C library (whose internal workings are not defined by ISO)
>receives some characters to put into a buffer before putting them to
>stdout.
stdout might or might not be 'buffered'.
>I hypothesise that in order to efficiently manage that buffer, a \b
>results in the last character being removed from the buffer, rather
>than sending it to the output device, and relying on hardware
>features.
Flaw in your hypothesis:
External devices are free to interpret and act
upon *any* character value in any way it chooses.
e.g. it might use '\b' as a command to open or
close a relay, etc. The most often seen (by me)
use of '\b' is indeed as a 'backspace character',
but there's certainly no requirement for this.
> Naturally, if you remove the -1th character, you're
>accessing memory you don't own. Naturally also there should be some
>protection against that, which is missing in the implementation.
So you think the language standard should limit
the interfaces of external hardware? :-)
>This to me seems a possible behaviour of stdout. Show me why its
>bullsh*t.
printf("%s\n", "It's \bullss*t");
See above.
-Mike
Lawrence Kirby
ma...@garthorn.demon.co.uk "Mark McIntyre" writes:
>On 26 Oct 2001 08:47:16 -0500, "Bart Kowalski" <m...@nospam.com> wrote:
>
>>"Mark McIntyre" <ma...@garthorn.demon.co.uk> wrote in message
>>news:iv3itt0av0fhicbaf...@4ax.com...
>>> On 26 Oct 2001 01:07:20 GMT, Dan...@cern.ch (Dan Pop) wrote:
>>>
>>> Let me refresh for you:
>>> the C library (whose internal workings are not defined by ISO)
>>> receives some characters to put into a buffer before putting them to
>>> stdout.
>>> I hypothesise that in order to efficiently manage that buffer, a \b
>>> results in the last character being removed from the buffer, rather
>>> than sending it to the output device, and relying on hardware
>>> features. Naturally, if you remove the -1th character, you're
>>> accessing memory you don't own. Naturally also there should be some
>>> protection against that, which is missing in the implementation.
>>>
>>> This to me seems a possible behaviour of stdout. Show me why its
>>> bullsh*t.
>>
>>stdio code runs in user mode.
>
>The user portion does, sure. At some point there's a kernel driver
>involved, to push data to the H/W. Maybe thats where the buffer is?
Your statement above referred to buffering implemented by "the C library"
and "before putting them to stdout". That strongly suggests user level
buffering and since we are discussing a problem with a specific known
platform (Windows) I think we can say that with reasonable certainty. I
agree that the problem is more likely to be at kernel level. There
certainly is a problem at kernel level, it shouldn't permit user level
code to initiate operations that crash the system.
Michael Wojcik
> If built with MSVC, it will not cause a reboot if invoked from a
> Cygwin shell, but will cause a reboot if invoked from a DOS shell or
> launched from Explorer.
I suspect another fatal bug in the "Command Prompt" console handler.
There's a well-documented bug in the NT (and 2000?) console command-
history editing feature that can cause a system crash and reboot
just by hitting the right keys while a console program is running.
(See the BUGTRAQ archives[1] if you're curious.) Apparently when
Microsoft moved a bunch of what should be user-level code into the
kernel for performance reasons in NT4, that included command-line
editing.
Another data point: I captured the output from several variations
posted here (when they didn't crash my machine), and took a hex dump,
and the characters were output in a different order from their
appearance in the literal string passed to printf. The "\t\b\b "
string appeared as \x08\x09\x20\x08, for example. This is NT4 SP6a
plus other fixes, MSVC 6.0 SP5, compiled from the command line with
default options.
The crash message reported a stop C000021A in the Windows Subsystem
with a status of C0000005 (5FFB365E 0124FAA0). That looks like a
memory protection violation to me.
Since this bug has already been widely announced, I'm going to send
a post to BUGTRAQ about it. I'll also send a note to Microsoft;
Bart said he would, but an extra won't hurt.
1. <url:http://www.securityfocus.com/>
--
Michael Wojcik michael...@microfocus.com
Comms Development, Micro Focus
Department of English, Miami University
Don't forget your fighting spirit at each balls you pitch!
-- Tornado Boy Volunteer Staff International
Michael Wojcik
In article <9r6ulg$6u5$1...@acs2.byu.edu>, Tyler Larson <ne...@t.larson.com> writes:
>
> The following updated code will *always* reboot your high-quality
> server machine with that $1000 MS operating system you put on it:
>
> #include <stdio.h>
> int main(void)
> {
> printf("\t\b\b ");
> return 0;
> }
This variant doesn't affect my test box, actually, though the
original does.
What's more, capturing a healthy chunk of output from the original in
a file (I grabbed around 24MB, just because that's how much had been
written when I killed the program) and then displaying that file in
a command-prompt window (with eg the "type" command) crashed NT.
So it appears this indeed has nothing to do with C.
--
Michael Wojcik michael...@microfocus.com
Comms Development, Micro Focus
Department of English, Miami University
Any average educated person can turn out competent verse. -- W. H. Auden
Mark McIntyre
>In <iv3itt0av0fhicbaf...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>
>>This to me seems a possible behaviour of stdout. Show me why its
>>bullsh*t.
>
>Because your hypothetical implementation doesn't match the specification
>from the standard:
Are you hard of reading?
0) The behaviour is stated as unspecified. In this instance that
equates to undefined because of a defect in the standard. Unspecified
behaviour has to have 2 or more alternatives defined in the standard.
But there are none here.
1) As I clearly said in my post, I'm not talkng about the interface
the standard library presents to C, we already know the implementation
isn't sticking to the spirit of that. I'm talking about the innards of
the library.
>BTW, the implementation code doesn't invoke undefined behaviour, as you
>wrote. Undefined behaviour is something for application code, not for
>implementation code.
What, so in implementation code, walking backwards off an array is
defined? Go on, do tell.
> Implementation code contains plenty of constructs that would
>invoke undefined behaviour if used in application
>code. Their behaviour is well defined,
I'm sure that in general thats true. But I can't agree that walking
backwards off an array is well defined in general. merely because its
implementation code.
>however, because this code is
>written by people who know what the compiler does and the code is not
>supposed to be compiled by other compilers.
You'd like to think so wouldn't you?
>The problem with your hypothesis is that the bug would be in the
>standard library implementation, which runs in userland,
Says who? How do you know how the library works - it could consist of
a user-mode portion statically linked to your app, which was able to
call a kernel-mode portion, and the bug could be in the latter.
Mark McIntyre
<mkwa...@ix.netcom.com> wrote:
>Mark McIntyre wrote in message ...
>>
>>I hypothesise that in order to efficiently manage that buffer, a \b
>>results in the last character being removed from the buffer, rather
>>than sending it to the output device, and relying on hardware
>>features.
>
>Flaw in your hypothesis:
let me remind you, its a hypothesis.
>External devices are free to interpret and act
>upon *any* character value in any way it chooses.
>e.g. it might use '\b' as a command to open or
>close a relay, etc. The most often seen (by me)
>use of '\b' is indeed as a 'backspace character',
>but there's certainly no requirement for this.
I'm not sure about the relevance of this. If anything it bolsters my
point - in order to send the *right* sequence of chars to the extermal
device, the library function must interpret the char stream sent by C.
>> Naturally, if you remove the -1th character, you're
>>accessing memory you don't own. Naturally also there should be some
>>protection against that, which is missing in the implementation.
>
>So you think the language standard should limit
>the interfaces of external hardware? :-)
No. Can you explain how that links to my previous remark?
>>This to me seems a possible behaviour of stdout. Show me why its
>>bullsh*t.
>
>printf("%s\n", "It's \bullss*t");
>See above.
Since you showed nothing above I'm still mystified !
Bart Kowalski
> On 26 Oct 2001 16:13:00 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
> >In <iv3itt0av0fhicbaf...@4ax.com> Mark McIntyre
<ma...@garthorn.demon.co.uk> writes:
> >
> > Implementation code contains plenty of constructs that would
> >invoke undefined behaviour if used in application
> >code. Their behaviour is well defined,
>
> I'm sure that in general thats true. But I can't agree that walking
> backwards off an array is well defined in general. merely because its
> implementation code.
Sure it is, because the implementation may have knowledge of what lies before
the array. malloc() implementations do this.
Bart.
Mark McIntyre
>"Mark McIntyre" <ma...@garthorn.demon.co.uk> wrote in message
>news:f7jjttooobne01sip...@4ax.com...
>> On 26 Oct 2001 16:13:00 GMT, Dan...@cern.ch (Dan Pop) wrote:
>>
>> >In <iv3itt0av0fhicbaf...@4ax.com> Mark McIntyre
><ma...@garthorn.demon.co.uk> writes:
>> >
>> > Implementation code contains plenty of constructs that would
>> >invoke undefined behaviour if used in application
>> >code. Their behaviour is well defined,
>>
>> I'm sure that in general thats true. But I can't agree that walking
>> backwards off an array is well defined in general. merely because its
^^^^^^^^^^^^^^
>> implementation code.
>
>Sure it is, because the implementation may have knowledge of what lies before
>the array.
/may/ have in specific, yes, but in general?
>malloc() implementations do this.
Indeed they _sometimes_ do. But why would they need to ?
And generally if you walk off the front they let you know by
signalling a memory violation ! Or maybe that happens all by itself...
Mike Wahler
Mark McIntyre wrote in message ...
>On Fri, 26 Oct 2001 10:32:41 -0700, "Mike Wahler"
><mkwa...@ix.netcom.com> wrote:
>
>>Mark McIntyre wrote in message ...
>>>
>>>I hypothesise that in order to efficiently manage that buffer, a \b
>>>results in the last character being removed from the buffer, rather
>>>than sending it to the output device, and relying on hardware
>>>features.
>>
>>Flaw in your hypothesis:
>
>let me remind you, its a hypothesis.
>
>>External devices are free to interpret and act
>>upon *any* character value in any way it chooses.
>>e.g. it might use '\b' as a command to open or
>>close a relay, etc. The most often seen (by me)
>>use of '\b' is indeed as a 'backspace character',
>>but there's certainly no requirement for this.
>
>I'm not sure about the relevance of this. If anything it bolsters my
>point - in order to send the *right* sequence of chars to the extermal
>device, the library function must interpret the char stream sent by C.
Interpret it as what? It simply passes the character
value on to the hardware device's interface, which
can interpret and act (or not) upon it in any manner.
>>> Naturally, if you remove the -1th character, you're
>>>accessing memory you don't own. Naturally also there should be some
>>>protection against that, which is missing in the implementation.
>>
>>So you think the language standard should limit
>>the interfaces of external hardware? :-)
>
>No. Can you explain how that links to my previous remark?
See above.
>
>>>This to me seems a possible behaviour of stdout. Show me why its
>>>bullsh*t.
>>
>>printf("%s\n", "It's \bullss*t");
>>See above.
>
>Since you showed nothing above I'm still mystified !
I'd say your remarks are mystifying. :-)
-Mike
Mark McIntyre
<mkwa...@ix.netcom.com> wrote:
>
>Mark McIntyre wrote in message ...
>>On Fri, 26 Oct 2001 10:32:41 -0700, "Mike Wahler"
>>>External devices are free to interpret and act
>>>upon *any* character value in any way it chooses.
>>>e.g. it might use '\b' as a command to open or
>>>close a relay, etc.
>>
>>I'm not sure about the relevance of this. If anything it bolsters my
>>point - in order to send the *right* sequence of chars to the extermal
>>device, the library function must interpret the char stream sent by C.
>
>Interpret it as what? It simply passes the character
>value on to the hardware device's interface, which
>can interpret and act (or not) upon it in any manner.
You were the one who introduced hardware where \b was not backspace,
so don't try now to claim the reverse now ! My point is, \b in C means
backspace. If an external device interprets that as "turn off the
monitor" then the C implementation would have to translate \b into the
right char, otherwise the implementation would not conform.
>>>> Naturally, if you remove the -1th character, you're
>>>>accessing memory you don't own. Naturally also there should be some
>>>>protection against that, which is missing in the implementation.
>>>
>>>So you think the language standard should limit
>>>the interfaces of external hardware? :-)
>>
>>No. Can you explain how that links to my previous remark?
>
>See above.
I repeat the question. Your remark above does _not_ link my comment to
any limitation placed on the H/W by the standard.
And by the way, YES I do think the standard should limit hardware. It
does in fact. It requires for instance at least 8 bit bytes.
>>>>This to me seems a possible behaviour of stdout. Show me why its
>>>>bullsh*t.
>>>
>>>printf("%s\n", "It's \bullss*t");
>>>See above.
>>
>>Since you showed nothing above I'm still mystified !
>
>I'd say your remarks are mystifying. :-)
Round and round and round we go.
Imanpreet Singh Arora
bug.
The reason is fairly simple if we look in terms of these programs
int main(void)
{
printf("Good\t\bSimple");//The \b is changed to the \bt i.e. back tab
return 0;
}
int main(void)
{
printf("\t\b\bTomy"); //Check out where the output goes.
return 0;
}
So apparently the when it reaches the topmost using while(1) of the
screen and then further tries to go up
there is no way to go up. Being a kid I cannot tell about what happens
when
we try to write against this but my rudimentery knowledge says that if
we
try to do something illegal it is *ILLEGAl*. I haven't till now done
file handling but I guess
if we reach the top of the file and then try to write still into the
file its illegal and
if the file is some kind of driver then it is definitely illegal.
P.S --> The most intersting propostiton comes in here because if we
have
int main(void)
{
printf("Simp\tKunf"); //TB == 4
printf("\n\tSimp");//TB = 8
return 0;
}
Mike Wahler
>On Fri, 26 Oct 2001 23:14:54 -0700, "Mike Wahler"
><mkwa...@ix.netcom.com> wrote:
[snip]
>>>Since you showed nothing above I'm still mystified !
>>
>>I'd say your remarks are mystifying. :-)
>
>Round and round and round we go.
Agreed, we'll probably never agree :-)
I think I'll go ahead and step off this particular
carousel and move on to something more interesting. :-)
-Mike
Ernst Rattenhuber
jer...@jdyallop.freeserve.co.uk says...
The cause of the crashes is in Microsoft's console window implementation. It's
not in the C libraries and it's not because of anything in a particular
compiler implementation. It's not a display driver issue either.
The same program (I used the smallest version, the one that just writes "\t\b\b
" to stdout, crashes Windows NT when run in a NT console window. On the same
computer, the same exe file does NOT crash the system when run in a MKS
(Mortice Kern Systems) Korn Shell window.
My guess would be that Mark McIntyre's guess is right. Each backspace
probably sets an index into a buffer back by 1. When the index goes below 0,
nasty things may happen because the console window implementation hasn't
safeguarded against it. Others obviously have done a better job than Microsoft;
I think I saw a post in this thread claiming similar results for NT console
window against some other kind of command line environment.
Ernst Rattenhuber
Bart Kowalski
process. An access violation occurs in csrss.exe, which shuts down that process,
which is a vital process of the system, and the entire system is shut down as a
result.
See:
http://homepages.tesco.net./~J.deBoynePollard/FGA/csrss-backspace-bug.html
Bart.
Mike Wahler
Bart Kowalski wrote in message <3bdb1cb5$0$74221$45be...@newscene.com>...
But do Bill and Steve know? :-)
-Mike
Bart Kowalski
news:9rfk7q$vte$1...@nntp9.atl.mindspring.net...
They should know by now. Whether they care is a different story. :)
Bart.
-hs-
> #include <stdio.h>
>
> int main(void)
> {
> while(1)
> printf("\t\t\b\b\b\b\b\b");
>
> return 0;
> }
No problem with Windows 98.
- BC 3.1
- DJGPP (ms-dos port of gcc)
--
-hs- emdel at noos.fr "support Afghans against Taleban"
"Car les bandits qui sont cause des guerres
N'en meurent jamais, on n'tue qu'les innocents."
Gaston Montéhus -- La Butte Rouge
Andrew Cady
> Jeremy Yallop wrote in message
> <9rbddl$sko2g$1...@ID-114079.news.dfncis.de>...
>
> > The code also causes a system reboot when compiled with MinGW.
> > The equivalent Java program has the same effect, FWIW.
>
> Well, that pretty much seals it. It's not a problem with a C
> implementation, but some OS 'internals' botch.
Why does that seal it? The Java interpreter is probably written in C;
the Java program could very well be using stdio. If you want to
figure out whether the C library is involved, you have to use the
lower-level write function/syscall that stdio uses. Of course, it has
to be a bug in priveleged code somewhere (i.e., *not* just the C
library) or the OS wouldn't crash.
Mark McIntyre
>"Mike Wahler" <mkwa...@ix.netcom.com> wrote in message
>news:9rfk7q$vte$1...@nntp9.atl.mindspring.net...
>>
>> Bart Kowalski wrote in message <3bdb1cb5$0$74221$45be...@newscene.com>...
>> >If anyone is still interested, it seems that the bug is in the Win32 subsystem
>> >process. An access violation occurs in csrss.exe, which shuts down that process,
>> >which is a vital process of the system, and the entire system is shut down as a
>> >result.
>> >
>> >See:
>> >http://homepages.tesco.net./~J.deBoynePollard/FGA/csrss-backspace-bug.html
>> >
>>
>> But do Bill and Steve know? :-)
>
>They should know by now. Whether they care is a different story. :)
<hubris>
I note with amusement that the cause seems to be pretty much what I
hypothesised. I also note with interest that it happens in kernel mode
code, despite what people said about that being impossible. Good old
MS....
</hubris>
Bart Kowalski
> <hubris>
> I note with amusement that the cause seems to be pretty much what I
> hypothesised. I also note with interest that it happens in kernel mode
> code, despite what people said about that being impossible. Good old
> MS....
> </hubris>
You mean it happens in *user mode* despite what people said about that being
impossible. :)
Bart.
Mark McIntyre
wrote:
>"Mark McIntyre" <ma...@garthorn.demon.co.uk> wrote in message
Either way does fine for me !
Dan Pop
A hasty conclusion. Java itself might be implemented in C and "inherit"
all the problems of the C implementation.
Dan Pop
>On 26 Oct 2001 16:13:00 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
>>In <iv3itt0av0fhicbaf...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>>
>>>This to me seems a possible behaviour of stdout. Show me why its
>>>bullsh*t.
>>
>>Because your hypothetical implementation doesn't match the specification
>>from the standard:
>
>Are you hard of reading?
>
>0) The behaviour is stated as unspecified. In this instance that
>equates to undefined because of a defect in the standard. Unspecified
>behaviour has to have 2 or more alternatives defined in the standard.
>But there are none here.
They are not explicitly mentioned, that's all. This is a quite frequent
case, BTW. The very example used to illustrate unspecified behavior
in the standard is one of them:
[#1] unspecified behavior
behavior where this International Standard provides two or
more possibilities and imposes no requirements on which is
chosen in any instance
[#2] EXAMPLE An example of unspecified behavior is the
order in which the arguments to a function are evaluated.
The standard doesn't explicitly define 2 or more alternatives for the
order of evaluation of function arguments, right?
>1) As I clearly said in my post, I'm not talkng about the interface
>the standard library presents to C, we already know the implementation
>isn't sticking to the spirit of that. I'm talking about the innards of
>the library.
Me too. Unspecified behaviour doesn't give them a licence to crash the
system.
>>BTW, the implementation code doesn't invoke undefined behaviour, as you
>>wrote. Undefined behaviour is something for application code, not for
>>implementation code.
>
>What, so in implementation code, walking backwards off an array is
>defined? Go on, do tell.
For *each* specific implementation it *is* defined. You may want to check
the example of a storage allocator in Chapter 8 of K&R2. In standard C,
the first statement of the free() implementation invokes undefined
behaviour.
>> Implementation code contains plenty of constructs that would
>>invoke undefined behaviour if used in application
>>code. Their behaviour is well defined,
>
>I'm sure that in general thats true. But I can't agree that walking
>backwards off an array is well defined in general.
Not in general, but for each implementation in particular. And, of
course, not "defined" in the C standard sense.
>merely because its implementation code.
Merely because it's implementation code it doesn't mean that it's bug
free, but this is another issue. My point is that the implementor does
know the effect of code that invokes undefined behaviour in standard C.
Furthermore, it is impossible to implement the C standard without such
code.
>>The problem with your hypothesis is that the bug would be in the
>>standard library implementation, which runs in userland,
>
>Says who? How do you know how the library works - it could consist of
>a user-mode portion statically linked to your app, which was able to
>call a kernel-mode portion, and the bug could be in the latter.
The distinction is quite clear in the real world: if it runs in user mode,
it's the C library, if it runs in kernel mode it's the OS, i.e. the host
environment.
willem veenhoven
>
> Mark McIntyre writes:
>
> > What, so in implementation code, walking backwards off an
> > array is defined? Go on, do tell.
>
> For *each* specific implementation it *is* defined. You may
> want to check the example of a storage allocator in Chapter 8
> of K&R2.
Storage allocators implemented by a number of today's popular
compilers seem to be influenced by this trick though. I remember
posting a debugging tip based on (HEADER *)ap-1 here, when someone
asked how to retrieve the size of a malloc'd memory block. I also
remember some regulars didn't exactly thank me for that reply ;-)
> the first statement of the free() implementation invokes
> undefined behaviour.
Nope. It's a C-feature, which is for instance also successfully
implemented by NR, and me. Richie just decided not to let all of
us know about this powerful tool of out-of-bound addressing;
therefore it is only known to the incrowd. So it's undocumented
behaviour rather than undefined behaviour for some of us ;-)
willem
Mark McIntyre
>In <f7jjttooobne01sip...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>
>>0) The behaviour is stated as unspecified. In this instance that
>>equates to undefined because of a defect in the standard. Unspecified
>>behaviour has to have 2 or more alternatives defined in the standard.
>>But there are none here.
>
>They are not explicitly mentioned, that's all. This is a quite frequent
>case, BTW.
Indeed. And technically each is a defect, since the definition of the
term requires defined behaviours. One for the ISO committee.
>Unspecified behaviour doesn't give them a licence to crash the
>system.
Since the standard fails to provide any alternatives, I don't think
its unreasonable to allow an implementation to, as you suggested
later, provide two alternatives of its own:
- set fire to your socks
- reboot your computer
>>>The problem with your hypothesis is that the bug would be in the
>>>standard library implementation, which runs in userland,
>>
>>Says who? How do you know how the library works - it could consist of
>>a user-mode portion statically linked to your app, which was able to
>>call a kernel-mode portion, and the bug could be in the latter.
>
>The distinction is quite clear in the real world: if it runs in user mode,
>it's the C library, if it runs in kernel mode it's the OS, i.e. the host
>environment.
I trust that you've by now seen the analysis of the problem, which I
regret disagrees with this hypothesis.