help-emacs-windows
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h-e-w] Emacs failing to start


From: Troy Daniels
Subject: Re: [h-e-w] Emacs failing to start
Date: Fri, 19 Mar 2010 23:32:03 -0400



On Wed, Mar 17, 2010 at 4:17 PM, Eli Zaretskii <address@hidden> wrote:

What happens if you run it under GDB to begin with -- does it also
hang when you type "run" at the GDB prompt?  If it does, perhaps step
through the `main' function and see where it hangs.

If I type run at the initial prompt, it hangs as usual.

If I type break main, run, step, I get a message that there is no line number information and it hangs.

If I type break main, run and stepi (a lot), I see the following:

main
  calls __main and returns
  calls sort_args
     calls xmalloc
        calls e_malloc and returns*
        calls emacs_blocked_malloc
           calls e_malloc and returns*
           calls _malloc_internal and returns*
           calls _mall0c_internal_nolock and returns
       emacs_blocked_malloc returns
    xmalloc returns
    calls xmalloc. 
    xmalloc returns after a similar call sequence
    calls xmalloc.  I used finish rather than step through the entire call
    calls memmove and returns
  sort_args returns after I use finish
  calls argmatch and returns
  calls clearerr and returns*
  calls msvcrt!clearerr from msvcrt..dll

* stepi stopped reporting that it was in the function, but went directly to the next function without every reporting that it was in the calling function.

At this point, it jumped to strerror.

(gdb) where
#0  0x77c37420 in strerror () from C:\WINDOWS\system32\msvcrt.dll
#1  0x0100124b in __mingw_CRTStartup ()
#2  0x01001298 in mainCRTStartup ()
#3  0x7c817077 in RegisterWaitForInputIdle ()
   from C:\WINDOWS\system32\kernel32.dll
#4  0x00000000 in ?? ()
(gdb) info thread
* 1 Thread 2796.0x634  0x77c37420 in strerror ()
   from C:\WINDOWS\system32\msvcrt.dll

stepi about 20 times gets me to

(gdb) stepi
0x77c3745a in strerror () from C:\WINDOWS\system32\msvcrt.dll
(gdb) stepi
0x77c409fd in msvcrt!clearerr () from C:\WINDOWS\system32\msvcrt.dll
(gdb) where
#0  0x77c409fd in msvcrt!clearerr () from C:\WINDOWS\system32\msvcrt.dll
#1  0x0061006d in ?? ()
#2  0x00730063 in ?? ()
#3  0x00000001 in ?? ()
#4  0x0083fed4 in ?? ()
#5  0x0100223d in main ()

A few more stepi and I'm at

(gdb) stepi
0x77c3b8da in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
(gdb) where
#0  0x77c3b8da in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
#1  0x0100223d in main ()

More stepi to

(gdb) where
#0  0x7c901000 in ntdll!RtlEnumerateGenericTableLikeADirectory ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x77c3a5eb in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
#2  0x77c3b900 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
#3  0x77c40a06 in msvcrt!clearerr () from C:\WINDOWS\system32\msvcrt.dll
#4  0x77c5fc80 in sys_nerr () from C:\WINDOWS\system32\msvcrt.dll
#5  0x0061006d in ?? ()
#6  0x00730063 in ?? ()
#7  0x00000001 in ?? ()
#8  0x0083fed4 in ?? ()
#9  0x0100223d in main ()

(I'm not familiar with gdb and it's been a while since I've done C programming.  Is it normal for the stack trace to jump around like this in windows programs?)

RtlEnumerate... returns normally.
Both _lock return normally
A few more stepi and we're at

(gdb) where
#0  0x77c3b941 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
#1  0x0100223d in main ()

Then we jump to

(gdb) where
#0  0x77c3a519 in unlock () from C:\WINDOWS\system32\msvcrt.dll
#1  0x77c3b967 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
#2  0x77c40a54 in msvcrt!clearerr () from C:\WINDOWS\system32\msvcrt.dll
#3  0x77c5fc80 in sys_nerr () from C:\WINDOWS\system32\msvcrt.dll
#4  0x77c40a45 in msvcrt!clearerr () from C:\WINDOWS\system32\msvcrt.dll
#5  0x0061006d in ?? ()
#6  0x00730063 in ?? ()
#7  0x00000001 in ?? ()
#8  0x0083fed4 in ?? ()
#9  0x0100223d in main ()

It's now late, and this isn't making much sense to me.  I run finish 3 times, and it hangs at

(gdb) where
#0  0x77c3b967 in msvcrt!_lock () from C:\WINDOWS\system32\msvcrt.dll
#1  0x77c40a54 in msvcrt!clearerr () from C:\WINDOWS\system32\msvcrt.dll
#2  0x77c5fc80 in sys_nerr () from C:\WINDOWS\system32\msvcrt.dll
#3  0x77c40a45 in msvcrt!clearerr () from C:\WINDOWS\system32\msvcrt.dll
#4  0x0061006d in ?? ()
#5  0x00730063 in ?? ()
#6  0x00000001 in ?? ()
#7  0x0083fed4 in ?? ()
#8  0x0100223d in main ()
(gdb) finish
Run till exit from #0  0x77c3b967 in msvcrt!_lock ()
   from C:\WINDOWS\system32\msvcrt.dll
0x77c40a54 in msvcrt!clearerr () from C:\WINDOWS\system32\msvcrt.dll
(gdb) finish
Run till exit from #0  0x77c40a54 in msvcrt!clearerr ()
   from C:\WINDOWS\system32\msvcrt.dll

After C-c, the stack trace is the familiar

(gdb) where
#0  0x7c90e514 in ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c90df5a in ntdll!ZwWaitForSingleObject ()
   from C:\WINDOWS\system32\ntdll.dll
#2  0x7c8025db in WaitForSingleObjectEx ()
   from C:\WINDOWS\system32\kernel32.dll
#3  0x00000769 in ?? ()
#4  0x00000000 in ?? ()
(gdb)

It's late and I need to go to bed.  Let me know if this makes any sense.

Troy












   
   
   
   


reply via email to

[Prev in Thread] Current Thread [Next in Thread]