On Thu 2020-05-21 16:42:39 +0100, Olaf Sulla wrote:
> Apologies,
>
> Additional info:
>
> Build:
> CYGWIN_NT-6.1 shackleton 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
>
> Redacted cygcheck report attached.
>
>
>
> On Thu 2020-05-
On Fri 2020-05-22 10:54:07 +0100, Olaf Sulla wrote:
> On Thu 2020-05-21 16:42:39 +0100, Olaf Sulla wrote:
> > Apologies,
> >
> > Additional info:
> >
> > Build:
> > CYGWIN_NT-6.1 shackleton 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
> > Windows 7 Professional Ver 6.1 Build 7601 Service Pack
Am 21.05.2020 um 17:42 schrieb Olaf Sulla via Cygwin:
Apologies,
Additional info:
Build:
CYGWIN_NT-6.1 shackleton 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
Redacted cygcheck report attached.
On Thu 2020-05-21 16:13:08 +0100, Ola
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.
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 know there was another failing attempt, but this was already corrected...
My real question now:
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, though, stackdump at every second cygwin
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 reserv
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\bin>as
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
> 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
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
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
have read the various messages on the list describing how to get to
those
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:
> 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. Might not be the one
in /usr/local/bin
--
Unsubs
There can be multiple causes for this behavior depending upon the
implementation of the C compiler. In all cases, you are over-writing an
area of storage allocated for the contents of the *a pointer. This area
may be in a initialized data segment (usually read-only), in a data
segment, or even t
Hello,
[ No Cygwin-specific issues here. ]
The compiler and / or linker are allowed to place those string literals in
read-only storage, and apparently gcc under Cygwin does just that.
If you modify your program like this:
-==-
#include
char *strsave(char *);
int main() {
// char *a =
===
- 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 overwrite a static memory area
19 matches
Mail list logo
