1.7.5: cygwin programs throw STATUS_ACCESS_VIOLATION exceptions

Yuval Emek yuval.emek@gmail.com
Sun Apr 25 15:06:00 GMT 2010


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



More information about the Cygwin mailing list