On Tue, Apr 20, 2010 at 17:26, Christopher Faylor wrote: > > On Tue, Apr 20, 2010 at 09:19:28AM +0300, Yuval Emek wrote: > >On Mon, Apr 19, 2010 at 20:48, Christopher Faylor wrote: > >> On Mon, Apr 19, 2010 at 10:48:18AM -0400, Larry Hall (Cygwin) wrote: > >>>On 4/19/2010 7:44 AM, Yuval Emek wrote: > >>>> On Mon, Apr 19, 2010 at 09:32, Christopher Faylor > >>>> <cgf-use-the-mailinglist-please...> ?wrote: > >>> ? ?^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>><http://cygwin.com/acronyms/#PCYMTNQREAIYR>. ?Feeding spammers just makes > >>>them hungry. > >>> > >>><snip> > >>> > >>>>> p.envptr is supposed to be filled in by the call to _cygwin_crt0_common > >>>>> in cygwin_attach_dll. ?It is supposed to be set to the address of the > >>>>> "environ" variable in the DLL. ?It is not supposed to be NULL. ?That > >>>>> assignment should actually not even be necessary but the fact that > >>>>> envptr may be NULL is a problem. ?Of course, it could just be some > >>>>> non-NULL garbage too. ?Running in gdb and getting a stack trace would be > >>>>> instructive. > >>>> > >>>> Can you be more specific? (I have been using cygwin for a while, but I > >>>> never debugged it beforehand.) > >>>> I can install gdb using setup.exe . What should I do then in order to > >>>> obtain a stack trace? > >>> > >>>Grab a snapshot from <http://cygwin.com/snapshots/>. ?You want the DLL > >>>and debugging info at least. > >> > >> And, assuming that you can actually run gdb, just "gdb bash" and then "r". > > > >I installed gdb and then downloaded the (latest) snapshots of > >cygwin1.dll and cygwin1.dbg and extracted then to /bin/ (replacing the > >previous cygwin1.dll) . > >Running gdb bash seems to fail since there are no debugging symbols. > >In particular, when typing r in the gdb prompt, I get the following > >output: > > > >Starting program: /usr/bin/bash > >[New thread 3800.0x15b4] > >(no debugging symbols found) > >(no debugging symbols found) > >(no debugging symbols found) > >[New thread 3800.0x13f4] > > > >[1]+ Stopped gdb bash > > > >(Makes sense, I guess, as bash was not compiled with debugging info.) > >Can I download debugging info for bash from somewhere? (As far as I > >understand, I don't even have the source code for bash.) > >Is there something else I can do? > > I'm not interested in bash symbols. > > In the above it sounds like you may actually be running gdb from bash. > > I suggested bash because I thought most cygwin programs were dying but, > on rereading the original report, you only mentioned xterm, emacs, and > subversion. So, the thing to try would be to run gdb on one of those > from a c:\> prompt. And, it really would be as simple as just typing: > > gdb svn > r > bt > > and reporting the backtrace. > > cgf >
I cannot produce a backtrace: I run gdb on emacs (from a dos command prompt). Then I set the arguments of emacs to --batch -l bar.el (which causes the aforementioned exception many times) and type run. In 2 out of three runs, I get a message that looks like: ***message begins*** Starting program: /cygdrive/c/cygwin/bin/emacs --batch -l bar.el [New thread 4980.0x14dc] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New thread 4980.0x1600] warning: ERROR !!! HeapSetInformation failed to set g_Heap to LFH warning: ERROR !!! HeapSetInformation failed to set g_SpyHeap to LFH [New thread 4980.0x798] [New thread 4980.0xdc0] warning: Lowest section in /cygdrive/c/Windows/system32/security.dll is .text at 00401000 [New thread 4980.0x1410] [New thread 4980.0x1700] (No files need saving) [New thread 4980.0xe24] 5 [main] emacs-X11 4040 exception::handle: Exception: STATUS_ACCESS_VIOLAT ION 723 [main] emacs-X11 4040 open_stackdumpfile: Dumping stack trace to emacs-X 11.exe.stackdump 8 [main] emacs-X11 2056 exception::handle: Exception: STATUS_ACCESS_VIOLAT ION 743 [main] emacs-X11 2056 open_stackdumpfile: Dumping stack trace to emacs-X 11.exe.stackdump 6 [main] emacs-X11 2948 exception::handle: Exception: STATUS_ACCESS_VIOLAT ION 719 [main] emacs-X11 2948 open_stackdumpfile: Dumping stack trace to emacs-X 11.exe.stackdump 6 [main] emacs-X11 1100 exception::handle: Exception: STATUS_ACCESS_VIOLAT ION 739 [main] emacs-X11 1100 open_stackdumpfile: Dumping stack trace to emacs-X 11.exe.stackdump [New thread 4980.0x12b8] Program exited normally. ***message ends*** Afterward, when typing bt, I receive a "No stack" message. A piece of info that may help: The message 6 [main] emacs-X11 4832 exception::handle: Exception: STATUS_ACCESS_VIOLAT ION 1113 [main] emacs-X11 4832 open_stackdumpfile: Dumping stack trace to emacs-X 11.exe.stackdump that accompanies about 50% of the emacs, xterm, svn invocations is sometimes followed by the following message: 6 [main] emacs 6076 fork: child -1 - died waiting for longjmp before initi alization, retry 0, exit code 0x600, errno 11 I don't know why but I cannot produce this latter message from within dbg. Any suggestions? > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
