On 22.07.2020 18:04, Fergus Daly via Cygwin wrote:
Lately I have been experiencing an xterm stackdump with varying triggers but all
leading to a forced exit. Here is typical output.
Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at eip=0045D5EF
eax=0092 ebx=80080300 ecx= edx= esi
Lately I have been experiencing an xterm stackdump with varying triggers but all
leading to a forced exit. Here is typical output.
Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at eip=0045D5EF
eax=0092 ebx=80080300 ecx= edx= esi=800D4C88 edi=
ebp=0004 esp=006BC820
.
>
>
>
> On Thu 2020-05-21 16:13:08 +0100, Olaf Sulla wrote:
> > Hi,
> >
> > I am now experiencing multiple crashes in mintty following the installation
> > of
> > mintty v3.1.5 earlier this morning.
> >
> > Typical stackdum
Professional Ver 6.1 Build 7601 Service Pack 1
> >
> > Redacted cygcheck report attached.
> >
> >
> >
> > On Thu 2020-05-21 16:13:08 +0100, Olaf Sulla wrote:
> > > Hi,
> > >
> > > I am now experiencing multiple crashes in mintty f
, Olaf Sulla wrote:
Hi,
I am now experiencing multiple crashes in mintty following the installation of
mintty v3.1.5 earlier this morning.
Typical stackdump:
Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at rip=00100438534^M
rax=03E8 rbx=401C0001 rcx=^M
rdx
Hi,
I am now experiencing multiple crashes in mintty following the installation of
mintty v3.1.5 earlier this morning.
Typical stackdump:
Exception: STATUS_INTEGER_DIVIDE_BY_ZERO at rip=00100438534^M
rax=03E8 rbx=401C0001 rcx=^M
rdx= rsi
cygwin.com
> Subject: RE: Python stackdump on "succesful" exit after import of
> python-requests
> Date: Tue, 2 Feb 2016 11:34:49 -0500
>
> Hi Robert,
>
> My experience with Python is very, very limited. The only reason I am looking
> into this issue is because o
l, is that where you found the problem initially?
Thanks,
Maarten
> From: robert.mart...@bell.ca
> To: maarten...@hotmail.com
> CC: cygwin@cygwin.com
> Subject: RE: Python stackdump on "succesful" exit after import of
> python-re
ug symbols for this?
Thanks,
Maarten Jacobs
> From: maarten...@hotmail.com
> To: cygwin@cygwin.com
> CC: robert.mart...@bell.ca
> Subject: RE: Python stackdump on "succesful" exit after import of
> python-requests
> Date: Mon, 1 Feb
--
> From: maarten...@hotmail.com
> To: cygwin@cygwin.com
> CC: robert.mart...@bell.ca
> Subject: RE: Python stackdump on "succesful" exit after import of
> python-requests
> Date: Mon, 1 Feb 2016 00:36:02 -0500
>
> I installed the d
cygwin.com
> CC: robert.mart...@bell.ca
> Subject: RE: Python stackdump on "succesful" exit after import of
> python-requests
> Date: Sun, 31 Jan 2016 23:55:14 -0500
>
> I realized that for me, the "work-around" to use python3 was not practical,
> so I
t; From: maarten...@hotmail.com
> To: robert.mart...@bell.ca; cygwin@cygwin.com
> Subject: RE: Python stackdump on "succesful" exit after import of
> python-requests
> Date: Sat, 30 Jan 2016 18:21:45 -0500
>
> Interesting - I had the same issue earlier this week; I work
the issue with python 2.7.
I ran into the issue when I was trying to build libvirt-python on Cygwin.
I'd be curious to know what the real root cause for this abort is.
Thanks,
Maarten Jacobs
From: robert.mart...@bell.ca
To: cygwin@cygwin.com
Subje
.10 (default, Jun 1 2015, 18:17:45)
[GCC 4.9.2] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> exit()
Aborted (core dumped)
And here is the stackdump
$ cat python2.7.exe.stackdum
mintty became unresponsible and it was unusual. so i quit it and got
stackdump.
as i don't have debug symbol for cygwin 1.7.10(0.259/5/3) 2012-02-05
12:36, following stacktrace is attached without any consideration
whether is relevant to cygwin1.dll or not.
Stack trace:
Frame Fun
On 1/3/2012 5:58 PM, Marc Girod wrote:
marco atzeri-4 wrote:
C:\cygwin\bin>ash ./rebaseall
chdir c:\cygwin\bin
dash -l -i -c "rebaseall"
Er... this should not have resulted in anything different from the previous,
right?
I guess "-c" is critical and "-l" puts a clean cygwin enviroment.
corrected...
My real question now: is the need for './peflagsall' in addition gone?
Marc
--
View this message in context:
http://old.nabble.com/Stackdump-at-every-second-startup-tp33071456p33073231.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem report
That seems to have done the trick. Thanks!
Børge
On Tue, Jan 3, 2012 at 15:25, marco atzeri wrote:
> On 1/3/2012 1:29 PM, Børge Strand-Bergesen wrote:
>>
>> Thanks,
>>
>> I hope I used the right syntax in cmd. I ran it as Admin. The result
>> is the same,
On 1/3/2012 1:29 PM, Børge Strand-Bergesen wrote:
Thanks,
I hope I used the right syntax in cmd. I ran it as Admin. The result
is the same, though, stackdump at every second cygwin startup.
Børge
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights
Thanks,
I hope I used the right syntax in cmd. I ran it as Admin. The result
is the same, though, stackdump at every second cygwin startup.
Børge
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\borge>cd \cygwin\bin
C:\cygwin\
On 1/3/2012 7:11 AM, Børge Strand-Bergesen wrote:
Hi guys,
I've been experienceing some error messages lately, so I did a fresh
resinstall of Cygwin on my Win7-64 machine. All settings left as
defaults. I tried alternating Run as Administrator during both setup
and when starting Cygwin. That did
Hi guys,
I've been experienceing some error messages lately, so I did a fresh
resinstall of Cygwin on my Win7-64 machine. All settings left as
defaults. I tried alternating Run as Administrator during both setup
and when starting Cygwin. That didn't seem to change much.
The strange thing is that
Sometimes it started properly but usually not.
$ screen --version
Screen version 4.00.03 (FAU) 23-Oct-06
$ screen
2 [main] screen 2876 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
1058 [main] screen 2876 open_stackdumpfile: Dumping stack trace to
screen.exe.stackdump
1. Lost red bold text - the escape code for red bold returns white bold;
curiously, the code for yellow plain and yellow underline or any yellow
against a background other than black, return as red.
2. Any "missed" command or command or script not found throws a line
"Aborted" and then a standar
On Jun 28 20:50, Ken wrote:
> >> Under 1.7.5-1 in Win 7 64-bit, attempting to launch an xterm
> results in a
> >> stackdump approximately 30%-40% of the time. However, under WinXP
> >> I have not experienced this issue.
> >>
> >> I applied the enti
>> Under 1.7.5-1 in Win 7 64-bit, attempting to launch an xterm results
in a
>> stackdump approximately 30%-40% of the time. However, under WinXP
>> I have not experienced this issue.
>>
>> I applied the entire "cygwin-inst-20100622.tar.bz2" snapshot
hich should have "Release Candidate" quality.
>
> Under 1.7.5-1 in Win 7 64-bit, attempting to launch an xterm results in a
> stackdump approximately 30%-40% of the time. However, under WinXP
> I have not experienced this issue.
>
> I applied the entire "cygwin-in
forward to release Cygwin 1.7.6 soon.
>
>Please test the latest developer snapshots at
http://cygwin.com/snapshots/
>which should have "Release Candidate" quality.
Under 1.7.5-1 in Win 7 64-bit, attempting to launch an xterm results in a
stackdump approximately 30%-40% of the time
Under 1.7.5-1 in Win 7 64-bit, attempting to launch an xterm results in a
stackdump approximately 30%-40% of the time. However, under WinXP
I have not experienced this issue.
I applied the entire "cygwin-inst-20100622.tar.bz2" snapshot to my Win7
installation and the same con
On Apr 15 17:01, Corinna Vinschen wrote:
> On Apr 15 10:54, Christopher Faylor wrote:
> > On Thu, Apr 15, 2010 at 10:29:24AM +0200, Corinna Vinschen wrote:
> > >On Apr 15 09:44, Rurik Christiansen wrote:
> > >> Hi,
> > >>
> > >> Is there a
> I'd be glad if you could do that. I'm so tangled up in the
> tty thingy.
That should be worth a gold star, IMO :)
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
On Apr 15 10:54, Christopher Faylor wrote:
> On Thu, Apr 15, 2010 at 10:29:24AM +0200, Corinna Vinschen wrote:
> >On Apr 15 09:44, Rurik Christiansen wrote:
> >> Hi,
> >>
> >> Is there a way to disable the stackdump ? ('ulimit -c 0' doesn'
On Thu, Apr 15, 2010 at 10:29:24AM +0200, Corinna Vinschen wrote:
>On Apr 15 09:44, Rurik Christiansen wrote:
>> Hi,
>>
>> Is there a way to disable the stackdump ? ('ulimit -c 0' doesn't seem to
>> do the trick)
>
>The only way to disable stackdum
On Apr 15 09:44, Rurik Christiansen wrote:
> Hi,
>
> Is there a way to disable the stackdump ? ('ulimit -c 0' doesn't seem to
> do the trick)
The only way to disable stackdumps right now is to use the respective
setrlimit(RLIMIT_CORE, ...) call within the application i
Hi,
Is there a way to disable the stackdump ? ('ulimit -c 0' doesn't seem to
do the trick)
Cheers,
--
Nothing is true. Everything is permitted.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: ht
On Fri, Apr 10, 2009 at 02:28:49PM -0700, Tarmik wrote:
>>I just checked in a fix which should keep the stack trace going even
>>when it finds a return address of zero.
>
>>It will be in the next cygwin snapshot at: http://cygwin.com/snapshots/
>>but be advised that this is a 1.7.x version of Cygwi
this message in context:
http://www.nabble.com/seg-fault-produces-stackdump-with-no-stack-trace-tp18777069p22994946.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/pro
David Arnstein wrote:
> Just today, I noticed that /usr/bin/clear will stack dump. This occurs
> in both mintty and rxvt.
>
> If I execute bash from the Windows "DOS box," I get this:
> 4 [main] clear 13352 _cygtls::handle_exceptions: Error while
> dumping state
> (probably corrupted stack)
Christopher Faylor writes:
> I just checked in a fix which should keep the stack trace going even
> when it finds a return address of zero.
That'll be great. Thanks much!
--Steve
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problem
On Fri, Aug 01, 2008 at 05:55:24PM +, Steve Waldo wrote:
>Thanks to all for your prompt replies! Much appreciated.
>
>I'm amazed that the stack trace is so wimpy.
You're right. The algorithm isn't really sophisticated but it shouldn't
be quite that bad.
I just checked in a fix which should k
Brian Dessent dessent.net> writes:
> (gdb) bt
> #0 0x in ?? ()
> #1 0x00401052 in letsCrash () at tc.c:4
> #2 0x00401083 in main () at tc.c:9
> (gdb)
Many thanks Brian! 'bt' was what I'd forgotten. Sorry about the newbie
mistake - I haven't used gdb in ages. I'm actually using 'ddd'
Steve Waldo wrote on 01 August 2008 18:55:
> The real crash is occurring too intermittently to catch it in the
> debugger.
You need the 'error_start' option of the CYGWIN environment variable;
check the cygwin user's guide for more info.
cheers,
DaveK
--
Can't think of a witty .sig
Steve Waldo wrote:
> Even the debugger didn't know where it was anymore! It's obvious in this case
> why it went off in the weeds, but I would have thought the stack would still
> be accessible.
Well of *course* the debugger doesn't know what 0x is because
that is not a valid program loca
Thanks to all for your prompt replies! Much appreciated.
I'm amazed that the stack trace is so wimpy. All I did to trigger the example
was to add a call to this function to intentionally crash:
int letsCrash()
{
int (*myfunc)() = 0;
return myfunc();
}
With the debugger, it produces the fo
On Fri, Aug 01, 2008 at 03:24:26PM +, Steve Waldo wrote:
>I've seen other postings that show stackdump examples that include the
>expected list of addresses in the stack trace. I'm not getting that
>list. When my app gets a seg fault it produces the expected sta
Steve Waldo wrote:
> but the resulting file contains no stack trace:
>
> $ cat ResourceMgr.exe.stackdump
> Exception: STATUS_ACCESS_VIOLATION at eip=
Right there you should see the problem. eip=0 means your program has
followed a null pointer and wandered off into lala land, so you
shou
Steve Waldo wrote on 01 August 2008 16:24:
> When my app gets a seg fault it produces the expected stackdump file:
>
> [1]- Segmentation fault (core dumped) ./ResourceMgr
>
> but the resulting file contains no stack trace:
> Is there a setting I'm missing somewher
Hello,
I've seen other postings that show stackdump examples that include the
expected list of addresses in the stack trace. I'm not getting that list. When
my app gets a seg fault it produces the expected stackdump file:
[1]- Segmentation fault (core dumped) ./ResourceMg
Recently on my work machine at Cygwin startup I am getting repeated
bash.exe.stackdump's of the form:
11 [unknown (0xF88)] bash 3036 _cygtls::handle_exceptions:
Exception: STATUS_ACCESS_VIOLATION
This phenomenon immediately followed a Vista update on 12/12/2007
managed by Windows.
Cygwin contin
I have recently installed part of cygwin so that I can attempt to build
Mozilla on windows 2000.
I have now had a Mozilla build fail due to make crashing. When I restarted
the build, make did not crash a second time.
The following was displayed in the window I was using for the build
make[4]
PS>>Tried 20051013 and it worked :-)))
CGF> I'm sorry that it didn't occur to me much
CGF> earlier that this was a cygwin
CGF> heap problem that was fixed in a snapshot.
CGF> I guess that, as a rule of thumb,
CGF> "try a snapshot" is always a good idea.
Not to be a total brown nose, but I'v
On Fri, Oct 14, 2005 at 10:15:36AM -0700, Peter J. Stieber wrote:
>PS = Peter J. Stieber
>PS>>One last post before calling it a night. I built a debug
>PS>> version of the cygwin DLL as well and installed it.
>PS>> Here is the latest gdb session:
>
>CGF> I don't remember if I suggested trying a sna
PS = Peter J. Stieber
PS>>One last post before calling it a night. I built a debug
PS>> version of the cygwin DLL as well and installed it.
PS>> Here is the latest gdb session:
CGF> I don't remember if I suggested trying a snapshot
CGF> but I'm wondering if a snapshot would just fix
CGF> your pro
On Thu, Oct 13, 2005 at 11:50:45PM -0700, Peter J. Stieber wrote:
>One last post before calling it a night. I built a debug version of the
>cygwin DLL as well and installed it. Here is the latest gdb session:
I don't remember if I suggested trying a snapshot but I'm wondering if
a snapshot would
One last post before calling it a night. I built a debug version of the
cygwin DLL as well and installed it. Here is the latest gdb session:
Attaching to program `/bin/ld.exe', process 304
[Switching to thread 304.0x990]
(gdb) bt
#0 0x7c901231 in ntdll!DbgUiConnectToDbg ()
from /cygdrive/c/W
CGF> It is useless. You probaby have to continue
CGF> after ld has been attached to see where the
CGF> SEGV really is coming from.
Thanks. Here is the result...
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU
OK. This time gdb seemed to attach to the broken ld process, but the
back trace still doesn't have symbols...
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to chan
On Thu, Oct 13, 2005 at 10:33:46PM -0700, Peter J. Stieber wrote:
>1. I built the binutils code from the source.
>2. I renamed /usr/bin/ld.exe to /usr/bin/ld-old.exe.
>3. I copies ld-new.exe to /usr/bin.
>
>The debug session that starts when ld crashes repeats
>
>Program received signal SIGSEGV, Se
. Note that the cygwin configure script[*] has a
>BD>> --enable-debugging switch, but this is for enabling lots of
>BD>> runtime consistency checks and extra verbosity -- it is not
>BD>> meant for enabling debug symbols, which you
>BD>>should get by default.
>
>
1. I built the binutils code from the source.
2. I renamed /usr/bin/ld.exe to /usr/bin/ld-old.exe.
3. I copies ld-new.exe to /usr/bin.
The debug session that starts when ld crashes repeats
Program received signal SIGSEGV, Segmentation fault.
over and over. It never seems to stop.
Was copying l
PS = Peter J. Stieber
PS>>> Sorry in advance for the stupid questions, but...
PS>>>
PS>>> I downloaded the binutils source package, and
PS>>> extracted the source. When
PS>>> I ran
PS>>>
PS>>> ./configure --help
PS>>>
PS>>> I didn't see a --enable-debug option or anything
PS>>> I though was equiva
his is for enabling lots of
BD>> runtime consistency checks and extra verbosity -- it is not
BD>> meant for enabling debug symbols, which you
BD>>should get by default.
CF> Is this dying in the cygwin DLL? I suspect that it isn't.
CF> The stackdump file would show if it
PS = Peter J. Stieber
PS>> Sorry in advance for the stupid questions, but...
PS>>
PS>> I downloaded the binutils source package, and
PS>> extracted the source. When
PS>> I ran
PS>>
PS>> ./configure --help
PS>>
PS>> I didn't see a --enable-debug option or anything
PS>> I though was equivalent. Am I
stency checks and
>extra verbosity -- it is not meant for enabling debug symbols, which you
>should get by default.
Is this dying in the cygwin DLL? I suspect that it isn't. The stackdump
file would show if it is, as would using CYGWIN error_start setting that
I mentioned previously.
"Peter J. Stieber" wrote:
> Sorry in advance for the stupid questions, but...
>
> I downloaded the binutils source package, and extracted the source. When
> I ran
>
> ./configure --help
>
> I didn't see a --enable-debug option or anything I though was
> equivalent. Am I missing something?
Norm
PS = Peter J. Stieber on 10/9/2005 7:59 PM:
PS It's attached. I added the -t command to the g++ command so
PS the loader would list the files it was processing when it breaks.
PS The name of the object file in the last line should be
PS SimpleInterpolationTable.o, but it gets trunc
On Mon, Oct 10, 2005 at 11:18:06AM -0400, Christopher Faylor wrote:
>On Mon, Oct 10, 2005 at 06:13:15AM -0600, Eric Blake wrote:
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>According to Peter J. Stieber on 10/9/2005 7:59 PM:
>>> It's attached. I added the -t command to the g++ command so
On Mon, Oct 10, 2005 at 06:13:15AM -0600, Eric Blake wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Peter J. Stieber on 10/9/2005 7:59 PM:
>> It's attached. I added the -t command to the g++ command so the loader
>> would list the files it was processing when it breaks. The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Peter J. Stieber on 10/9/2005 7:59 PM:
> It's attached. I added the -t command to the g++ command so the loader
> would list the files it was processing when it breaks. The name of the
> object file in the last line should be SimpleInterpo
Peter J. Stieber wrote:
[snip]
> Yes. I manually typed the g++ line in the attached output file. It broke
> as well.
>
> Thanks for trying to help René. Any other suggestions?
Nothing seems out of the ordinary.
Have you tried the obvious, roll back binutils to a previous version? Or any
other t
PS = Peter J. Stieber
PS>> I have a large simluation that I have built under cygwin for a
PS>> quite a while. Recently the ld phase of the build started
PS>> generating a stackdump (ld.exe.stackdump).
PS>>
PS>> Unfortunately I cannot recreate the problem with a
Peter J. Stieber wrote:
> I have a large simluation that I have built under cygwin for a quite a
> while. Recently the ld phase of the build started generating a stackdump
> (ld.exe.stackdump).
>
> Unfortunately I cannot recreate the problem with a simple test case. I
> have
> From: "emacs user" <[EMAIL PROTECTED]>
> Bcc:
> Date: Tue, 16 Aug 2005 04:47:39 -0400
> Cc: cygwin@cygwin.com, [EMAIL PROTECTED], [EMAIL PROTECTED],
> emacs-devel@gnu.org
>
> here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
> absence of a detailed gdb GC debugging w
emacs user wrote:
> here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
> absence of a detailed gdb GC debugging which I dont know how to do, does
> this help?
I don't know anything about emacs, but I don't think this will help
anyone find the problem. A stack trace witho
here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
absence of a detailed gdb GC debugging which I dont know how to do, does
this help?
Exception: STATUS_ACCESS_VIOLATION at eip=610C4974
eax=21121CB8 ebx=8014 ecx=2005 edx= esi=A1121CC8
edi=A315B51C
ebp=0
On Sun, Jan 02, 2005 at 01:55:03PM -0500, Jon A. Lambert wrote:
>Christopher Faylor wrote:
>>On Sat, Jan 01, 2005 at 03:54:23AM -0500, Jon A. Lambert wrote:
>>>my application. I tried various means of examining and setting the
>>>registers in the stack to get to a frame that was within my app. I
my application fast. If you look at his posted stackdump though
you'll see it's definitely in userland, readable and more than enough
information to solve the problem. That is easily pinpoint the problem had
it been a real application.
I used his solution here:
http://www.cygwin.com/m
On Sat, Jan 01, 2005 at 03:54:23AM -0500, Jon A. Lambert wrote:
>I was having this difficulty debugging a crashed application. I was using
>Cygwin environmental variable error_start to either call dumper or gdb.
>Both a core dump and invoking gdb didn't show anything relevant to
>my application.
From: "Jon A. Lambert" <[EMAIL PROTECTED]>
--- environ.cc.orig 2005-01-01 03:15:33.913185600 -0500
+++ environ.cc 2005-01-01 03:16:55.670747200 -0500
+ int tracesize = strtol (buf, NULL, 0);
Sorry I diffed in the wrong dir, that should be..
tracesize = strtol (buf, NULL, 0);
--
Unsubscribe info:
resulting stackdump file looked great. That is to say it was a nice
clean stack that described a normal screwup on my part. The only
problem with it was it only displays 16 entries. Well I needed more
to pinpoint the problem because my app is pretty deeply nested.
Well I patched up my cygwin and rec
I just compiled the cygwin dll from latest CVS, and the problem reported in
this thread, ie the script:
--
#!/bin/bash
echo foo
sleep 10
--
When run with "setsid bash script.sh" no longer produces a stackdump and works
correctly.
--
Rafael
--
Unsubs
On Thu, 22 Jan 2004, David Rothenberger wrote:
> Rafael Kitover wrote:
>
> > I would dearly love to know how you get those lovely line numbers in the
> > stackdump :)
>
> I used the unstripped DLL from my CVS build and then used addr2line on
> each function address in
Rafael Kitover wrote:
I would dearly love to know how you get those lovely line numbers in the
stackdump :)
I used the unstripped DLL from my CVS build and then used addr2line on
each function address in the stacktrace, specifying the DLL as the
executable. I.e.,
addr2line -e /bin/cygwin1.dll
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>David Rothenberger
>Sent: Thursday, January 22, 2004 10:32 AM
>To: [EMAIL PROTECTED]
>Subject: bash, dircolors, setsid and a stackdump
>
>I've just encountered a very strange p
fault /etc/profile
and am using the default /etc/DIR_COLORS.
I start an rxvt window with "rxvt -e bash --login -i". From that
window, I execute "setsid bash script.sh" and get a stackdump from
sleep.exe.
---begin stackdump---
Exception: STATUS_ACCESS_VIOLATION at eip=6100256C
Hello,
I have a problem with inetd.exe.
The connection is closed by foreign host just after i open it.
I have try inetd -d and i can see that the process says
# 348 [main] inetd 816 sync_with_child: child 2644(0x55C) died before
initialization with status code 0x18B00
As shown in attached file ine
> 1. I have a specific program which I have in /usr/local/bin
> and it is in my
> path.
>
>-> gives a stackdump (.stackdump file)
>
>however if I do
>/usr/local/bin/ -> works fine!!
$ type -a
and see what you're actually executing. Mig
folks!
I need your help (cygwin latest version 1.3.19.1 although the problem may not
be related to the version)
1. I have a specific program which I have in /usr/local/bin and it is in my
path.
-> gives a stackdump (.stackdump file)
however if I do
/usr/local/bin/ -> work
On Mon, 3 Feb 2003, Gerrit Cap wrote:
> Hello
>
> A few weeks ago I build an xplanet.exe file from the sources (which is now
> being published by Hans Ecke's XPlanet website http://hans.ecke.ws/xplanet
> and he sent me from a user that had a problem resulting in a stackdump
&g
Hello
A few weeks ago I build an xplanet.exe file from the sources (which is now
being published by Hans Ecke's XPlanet website http://hans.ecke.ws/xplanet
and he sent me from a user that had a problem resulting in a stackdump
file. My question is rather simple: the xplanet.exe.stackdump
ion 2.95.3-5(cygwin)
>
> [Question]
> The compilation is passed, but after running the a.exe, the
> following message appeared and I got a a.exe.stackdump too.
> --
> string_a = I am a teacher
> string_b = You are a student
> 0 [main] a 1536 open stackdumpfile:Dumpi
The compilation is passed, but after running the a.exe, the
>following message appeared and I got a a.exe.stackdump too.
>--
>string_a = I am a teacher
>string_b = You are a student
> 0 [main] a 1536 open stackdumpfile:Dumping stack trace to a.exe
>stackdump
>Segmentation fault (core dumped)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
===
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 07, 2002 2:09 PM
Subject: stackdump about C language
> Hi, gentleman, could you do me a favour?
> I had some trouble in running a C program.
You are trying to overwri
ng the a.exe, the
following message appeared and I got a a.exe.stackdump too.
--
string_a = I am a teacher
string_b = You are a student
0 [main] a 1536 open stackdumpfile:Dumping stack trace to a.exe
stackdump
Segmentation fault (core dumped)
--
[Misc]
The contents of a.
94 matches
Mail list logo
