ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-apps/2001/09/20/15:41:41

Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: <cygwin-apps AT cygwin DOT com>
Subject: RE: get windows error message 0xc0000142 on starting cygwin app
Date: Thu, 20 Sep 2001 21:45:45 +0200
Message-ID: <016301c1420c$d6c91e30$af6407d5@BRAMSCHE>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <20010920145015.A30281@redhat.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

> On Thu, Sep 20, 2001 at 08:46:07PM +0200, Ralf Habacker wrote:
> >< On Wed, Sep 19, 2001 at 04:53:09PM +0200, Ralf Habacker wrote:
> >> >> No, I mean that an instruction that manipulates the stack results in an
> >> >> error.  That indicates to me that the stack pointer is screwed up.
> >> >>
> >> >But that would be code in the ntdll.dll or kernel32.dll ? But as
> I understand
> >> >does this code uses the stack of the current process, that is for
> >> example bash
> >> >or ssp or gdb, isn't it ?
> >>
> >> If you don't think it's the stack pointer, you can verify the issue very
> >> quickly.  Inspect it in gdb.
> >>
> >> (gdb) info reg $es
> >> (gdb) x/20x $esp
> >>
> >Can you tell me to which adress the stack is be set on starting a new app ?
> Maybe.  Can you tell me the air speed velocity of an unladen swallow?  :-)
Perhaps :-)

> Why are we moving on to another subject?  What was the result of the
> above investigation?
The question is quite a little bit unspecific. I should have inform you that
I'm familiar with such stuff because I have developed m68k assembler/c/c++
based embedded operation systems with asm debugger, scsi driver, gui and so
on for about 9 years. But this relates to m68k, on windows systems I have to
learn some difference. :-)

So on starting an app the stack pointer is set depending on the used memory
layout, some system build first the text than data, than bss and than the
stack segment. Currently I don't know how this it done on windows.

So assuming the above schema, the inital stack pointer could be calculated by
adding each sections size.

When starting gdb and doing "info reg $esp" gdb says "The program has no
registers now."
Setting a breakpoint at the first possible point seems to be MainCRTStartup
doesn't work,
because the error occurs before this point.
Starting an app with "r" says

(gdb) r
Starting program: /opt/kde2/bin/kjezz.exe
gdb: unknown target exception 0xc0000142 at 0x77fb00ac

Program received signal ?, Unknown signal.
0x77fb00ac in ?? ()
(gdb) info reg $esp
esp            0xaafc50 0xaafc50
(gdb) x/20x $esp
0xaafc50:       0xc0000142      0x00000001      0x00000000      0x77fb00ac
0xaafc60:       0x00000000      0x00580056      0x00020c7c      0x00560054
0xaafc70:       0x00020c24      0x00020c66      0x02080094      0x00020290
0xaafc80:       0x77f99c29      0xc0000145      0x00000001      0x00000000
0xaafc90:       0x00aafca8      0x00000001      0x00aafc9c      0x00000000

So to get some infos before I have send a CRTL-C signal immediatly after
entering the "r" command

Starting program: /opt/kde2/bin/kjezz.exe

Program received signal SIGINT, Interrupt.
[Switching to thread 1948.0x5f4]
0x77eb7763 in _libkernel32_a_iname ()
(gdb) Quit
(gdb) info reg $esp
esp            0xbeff24 0xbeff24
(gdb) x/20x $esp
0xbeff24:       0x00000001      0x00000000      0x00000000      0x812b56a0
0xbeff34:       0x00000000      0x40010005      0x00000000      0x00000000
0xbeff44:       0x77eb7763      0x00000000      0x812b5800      0x812b56a0
0xbeff54:       0x00000000      0xe214db08      0x00000000      0xe214db08
0xbeff64:       0x00000000      0xbcbabcac      0xe2142ae0      0x00780010

And this is a stack of another app stopped at MainCRTStartup
(gdb) info reg $esp
esp            0x22ffc4 0x22ffc4
(gdb) x/20x $esp
0x22ffc4:       0x77e892a6      0x77e73430      0xffffffff      0x7ffdf000
0x22ffd4:       0x0000001f      0x0022ffc8      0x0000001f      0xffffffff
0x22ffe4:       0x77e8dcbe      0x77e892b0      0x00000000      0x00000000
0x22fff4:       0x00000000      0x00401000      0x00000000      0x000000c8
0x230004:       0x00000100      0xeeffeeff      0x50000062      0x40000060

Is the stack in 2. same stack as in 1. or is this another. ?
If this is the same the used stack is about 1311444 byte (1,25 MB). That should
be no problem

Additional I have found two threads in this case. Does the threads are using the
same stack. ?

(gdb) info thread
* 2 thread 1948.0x5f4  0x77eb7763 in _libkernel32_a_iname ()
  1 thread 1948.0x8b4  0x77f8216a in ?? ()

After continuing one thread is gone.

(gdb) c
gdb: unknown target exception 0xc0000142 at 0x77fb00ac
Program received signal ?, Unknown signal.
[Switching to thread 1948.0x8b4]
0x77fb00ac in ?? ()
(gdb) info thread
* 1 thread 1948.0x8b4  0x77fb00ac in ?? ()
(gdb) bt
#0  0x77fb00ac in ?? ()
#1  0x77f975ba in ?? ()

> You can find the answer to this question by writing an app and inspecting
> its stack.

But if you compare 1. and 3. you can see different stacks because
I dont' think that the stacksize is about 9,7MB.

The next example shows another app:

(gdb) b *0x00401000
Breakpoint 1 at 0x401000
(gdb) r
Starting program: /opt/kde2/bin/kicker.exe
Program received signal SIGINT, Interrupt.
[Switching to thread 1332.0x938]
0x77eb7763 in _libkernel32_a_iname ()
(gdb) info reg $esp
esp            0xdcff24 0xdcff24
(gdb) c
[Switching to thread 1332.0x640]

Breakpoint 1, 0x00401000 in _size_of_heap_reserve__ ()
(gdb) info reg $esp
esp            0x22ffc4 0x22ffc4

> It is not at a fixed address but it probably usually shows
> up in roughly the same place in most apps.  I'm not sure why that's
> important.
See above

Perhaps this help


- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019