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: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com From: "Ralf Habacker" To: 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 1. (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 2. 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 3. (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 (gdb) 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 Continuing. 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 Continuing. [Switching to thread 1332.0x640] Breakpoint 1, 0x00401000 in _size_of_heap_reserve__ () (gdb) info reg $esp esp 0x22ffc4 0x22ffc4 (gdb) > 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 Regards Ralf