Watcom turns into immortal zombie

QNX Newsgroups (Archives) qdn.public.qnx4.devtools
1

Unfortunately it’s no joke - there seems to be a bug in watcom which
causes it to lock and go into an unkillable state, sucking up CPU time
and preventing furthur wcc386 processes from completing.

Has anyone else experience it, perhaps know of a workaround? At this
point there is no hope for a bugfix of the deceased watcom compiler, but
if I can somehow avoid this from happening it would prevent me from
having to reboot every time I compile.

Is there a utility which is stronger than ‘slay’? kill -9 won’t do it
either, I’m afraid.

Please email as well as post since I may not be checking this board
regularly.

Thanks,

Chuck Thomas

2

I saw this before.

first step “slay -sSIGSTOP wcc386”
second step “slay -9 wcc386”
=> root rights would be a good choise at this
point

–
Bye Sascha( sascha@bitctrl.de )

Sascha Morgenstern
BitCtrl Systems GmbH
Weißenfelser Straße 67
Germany - 04229 Leipzig
Phon. +49 341 490 670
FAX. +49 341 490 67 15
eMail: sascha@bitctrl.de
WWW: http://www.bitctrl.de


“C. Thomas” <cthomas@asa.bc.ca> schrieb im Newsbeitrag
news:3AF9BFE7.1000703@asa.bc.ca…

Unfortunately it’s no joke - there seems to be a bug in watcom which
causes it to lock and go into an unkillable state, sucking up CPU time
and preventing furthur wcc386 processes from completing.

Has anyone else experience it, perhaps know of a workaround? At this
point there is no hope for a bugfix of the deceased watcom compiler, but
if I can somehow avoid this from happening it would prevent me from
having to reboot every time I compile.

Is there a utility which is stronger than ‘slay’? kill -9 won’t do it
either, I’m afraid.

Please email as well as post since I may not be checking this board
regularly.

Thanks,

Chuck Thomas

3

Ups.

after the second step
third step “slay -sSIGCONT wcc386”

\

Bye Sascha( sascha@bitctrl.de )

Sascha Morgenstern
BitCtrl Systems GmbH
Weißenfelser Straße 67
Germany - 04229 Leipzig
Phon. +49 341 490 670
FAX. +49 341 490 67 15
eMail: sascha@bitctrl.de
WWW: http://www.bitctrl.de


“Sascha Morgenstern” <sascha@bitctrl.de> schrieb im Newsbeitrag
news:9dd8qe$sm6$1@inn.qnx.com…

I saw this before.

first step “slay -sSIGSTOP wcc386”
second step “slay -9 wcc386”
=> root rights would be a good choise at this
point

–
Bye Sascha( > sascha@bitctrl.de > )

Sascha Morgenstern
BitCtrl Systems GmbH
Weißenfelser Straße 67
Germany - 04229 Leipzig
Phon. +49 341 490 670
FAX. +49 341 490 67 15
eMail: > sascha@bitctrl.de
WWW: > http://www.bitctrl.de


“C. Thomas” <> cthomas@asa.bc.ca> > schrieb im Newsbeitrag
news:> 3AF9BFE7.1000703@asa.bc.ca> …
Unfortunately it’s no joke - there seems to be a bug in watcom which
causes it to lock and go into an unkillable state, sucking up CPU time
and preventing furthur wcc386 processes from completing.

Has anyone else experience it, perhaps know of a workaround? At this
point there is no hope for a bugfix of the deceased watcom compiler, but
if I can somehow avoid this from happening it would prevent me from
having to reboot every time I compile.

Is there a utility which is stronger than ‘slay’? kill -9 won’t do it
either, I’m afraid.

Please email as well as post since I may not be checking this board
regularly.

Thanks,

Chuck Thomas

4

The problem is not with watcom at all. I’d bet you have a programming
running at priority 10 taking away all the cpu from watcom.

Because watcom start with “other” scheduling it will lower its
priority (usually 9) while working. Hence if a program is running
at priority above 9, the kernel won’t give CPU time to watcom
(or any other program) and it won’t respond to the kill request.

Try running sac -i1 while this is happening.

“C. Thomas” <cthomas@asa.bc.ca> wrote in message
news:3AF9BFE7.1000703@asa.bc.ca…

Unfortunately it’s no joke - there seems to be a bug in watcom which
causes it to lock and go into an unkillable state, sucking up CPU time
and preventing furthur wcc386 processes from completing.

Has anyone else experience it, perhaps know of a workaround? At this
point there is no hope for a bugfix of the deceased watcom compiler, but
if I can somehow avoid this from happening it would prevent me from
having to reboot every time I compile.

Is there a utility which is stronger than ‘slay’? kill -9 won’t do it
either, I’m afraid.

Please email as well as post since I may not be checking this board
regularly.

Thanks,

Chuck Thomas

5

You were right.

I found a process running at 10 in a tight loop using Yield().
Seems Yield() won’t yield after all, to processes of a lesser priority…

Won’t make that mistake again.

Thanks to everybody who wrote in to help.

Chuck


Mario Charest wrote:

The problem is not with watcom at all. I’d bet you have a programming
running at priority 10 taking away all the cpu from watcom.

Because watcom start with “other” scheduling it will lower its
priority (usually 9) while working. Hence if a program is running
at priority above 9, the kernel won’t give CPU time to watcom
(or any other program) and it won’t respond to the kill request.

Try running sac -i1 while this is happening.

“C. Thomas” <> cthomas@asa.bc.ca> > wrote in message
news:> 3AF9BFE7.1000703@asa.bc.ca> …

Unfortunately it’s no joke - there seems to be a bug in watcom which
causes it to lock and go into an unkillable state, sucking up CPU time
and preventing furthur wcc386 processes from completing.

Has anyone else experience it, perhaps know of a workaround? At this
point there is no hope for a bugfix of the deceased watcom compiler, but
if I can somehow avoid this from happening it would prevent me from
having to reboot every time I compile.

Is there a utility which is stronger than ‘slay’? kill -9 won’t do it
either, I’m afraid.

Please email as well as post since I may not be checking this board
regularly.

Thanks,

Chuck Thomas

6

You were right.

I found a process running at 10 in a tight loop using Yield().
Seems Yield() won’t yield after all, to processes of a lesser priority…

Won’t make that mistake again.

Thanks to everybody who wrote in to help.

Chuck


Mario Charest wrote:

The problem is not with watcom at all. I’d bet you have a programming
running at priority 10 taking away all the cpu from watcom.

Because watcom start with “other” scheduling it will lower its
priority (usually 9) while working. Hence if a program is running
at priority above 9, the kernel won’t give CPU time to watcom
(or any other program) and it won’t respond to the kill request.

Try running sac -i1 while this is happening.

“C. Thomas” <> cthomas@asa.bc.ca> > wrote in message
news:> 3AF9BFE7.1000703@asa.bc.ca> …

Unfortunately it’s no joke - there seems to be a bug in watcom which
causes it to lock and go into an unkillable state, sucking up CPU time
and preventing furthur wcc386 processes from completing.

Has anyone else experience it, perhaps know of a workaround? At this
point there is no hope for a bugfix of the deceased watcom compiler, but
if I can somehow avoid this from happening it would prevent me from
having to reboot every time I compile.

Is there a utility which is stronger than ‘slay’? kill -9 won’t do it
either, I’m afraid.

Please email as well as post since I may not be checking this board
regularly.

Thanks,

Chuck Thomas

7

C. Thomas <cthomas@asa.bc.ca> wrote:

You were right.

I found a process running at 10 in a tight loop using Yield().
Seems Yield() won’t yield after all, to processes of a lesser priority…

Yield() isn’t supposed to yield to processes at a lower priority.
Yield() will move a process from the front of the queue at its priority
to the back of the queue at its priority. If it is the only process
at its priority, it will have (almost) no effect.

-David

QNX Training Services
dagibbs@qnx.com

(* almost no, in that it will be a kernel call, which will use more CPU
than not calling Yield().)

8

I have seen this. It happens fairly consistently when you are doing large
makes and you try to Control-C at some critical stage.

I’ve found that dropping a SIGSEGV on the process will kill just about
anything.

“C. Thomas” <cthomas@asa.bc.ca> wrote in message
news:3AF9BFE7.1000703@asa.bc.ca…

Unfortunately it’s no joke - there seems to be a bug in watcom which
causes it to lock and go into an unkillable state, sucking up CPU time
and preventing furthur wcc386 processes from completing.

Has anyone else experience it, perhaps know of a workaround? At this
point there is no hope for a bugfix of the deceased watcom compiler, but
if I can somehow avoid this from happening it would prevent me from
having to reboot every time I compile.

Is there a utility which is stronger than ‘slay’? kill -9 won’t do it
either, I’m afraid.

Please email as well as post since I may not be checking this board
regularly.

Thanks,

Chuck Thomas