Robert Pendell | 1 Aug 02:00 2008

GCC 3.4.4-3 in version 1.7 produces an error during setup


Ok.  I finally decided to do the update to 1.7 and in being that I like
to make sure there are no conflicts I dumped my entire 1.5 install that
I had working.  While trying to install gcc I get the following error...

Can't open
file://C:\cygwin\packages/http%3a%2f%2fcygwin.elite-systems.org%2f/release-2/gcc/gcc-3.4.4-3.tar.bz2
for reading: Invalid or unsupported tar format.

Just in case I tried another mirror.  Afterwards I checked it on the
server.  The actual archive is empty.  When the 1st level compression is
removed (only a tar file) then I did a hex dump and it looks like it is
just a filler file that contains only hex 00 in it.

Any chance we might be able to fix this error in the installer.  I can
tell this method was intentional but the error kinda threw me off.  This
was using the latest cygwin 1.7 installer file.
--
Robert Pendell
shinji <at> elite-systems.org

"A perfect world is one of chaos."

Thawte Web of Trust Notary
CAcert Assurer
Tomi Belan | 1 Aug 10:03 2008
Picon

Limited regex support in newlib cripples syntax highlighting in nano

Cygwin regex.h implementation doesn't support some special sequences,
for example \< (beginning of word), \> (end of word) and \b (word
boundary). This causes a usability bug with the nano editor, which
uses these sequences extensively in most of its syntax highlighting
rules. For example, in /usr/share/nano/c.nanorc, one of the rules goes
like this:
color brightyellow "\<(for|if|while|do|else|case|default|switch)\>"
\< and \> are used so that other words, e.g. 'fifo', 'elsewhere',
'undo' don't match, as they aren't keywords.

Test case 1:
Open nano and write a test message, for example "if a fifo is full".
Do a regexp search (using ^W M-R) for "\<if\>". No matches will be
found, because \< and \> don't have their special meaning and simply
match the characters < and >.

Test case 2:
To include C syntax rules, do: echo 'include
"/usr/share/nano/c.nanorc"' >> ~/.nanorc
Open a C source file in nano. Enable syntax highlighting with M-Y.
Strings and preprocessor instructions are highlighted (because those
rules don't contain \< \>), but keywords (e.g. if, for, return)
aren't.

I tested both nano 2.0.6 (currently in cygwin) and 2.0.7 (latest
stable version, compiled manually from source). The problem wasn't
present in Linux glibc nano 2.0.7. When I found out that Cygwin uses
newlib instead of glibc, it led me to believe that insufficient regex
support in newlib might be the cause.

(Continue reading)

Bayu Adiwibowo | 1 Aug 16:55 2008
Picon

grep exit with STATUS_ACCESS_VIOLATION error

When I try to make Portable Cygwin running from USB, I using batch
script to install cygwin automatically and call sh script to make cygwin
user account. Unfortunately after several test and tunning my script
exited with STATUS_ACCESS_VIOLANTION error and make system unstable.
When i try to run my script again unfortunately i can't reproduce this
error again for further investigation. I wonder if it's just temporary
error or some thing wrong with my script, also maybe some one can give
me suggestion to improve my script.

I run cygwin 1.5.25 in Windows XP 2002 SP2 with Intel Pentium MMX 250
MHz with 128 ram

I attach my script, cygcheck output and grep stackdump file


Cygwin Configuration Diagnostics
Current System Time: Fri Jul 18 21:33:34 2008

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:	d:\cygwin\usr\local\bin
	d:\cygwin\bin
	d:\cygwin\bin
	d:\cygwin\usr\X11R6\bin
	c:\WINDOWS\system32
	c:\WINDOWS
	c:\WINDOWS\System32\Wbem
	d:\cygwin\bin
(Continue reading)

Steve Waldo | 1 Aug 17:24 2008
Picon

seg fault produces stackdump with no stack trace

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) ./ResourceMgr

but the resulting file contains no stack trace:

$ cat ResourceMgr.exe.stackdump 
Exception: STATUS_ACCESS_VIOLATION at eip=00000000
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=611021A0 edi=004026B4
ebp=0022CC28 esp=0022CC1C program=c:\code\ResourceMgr\ResourceMgr.exe, pid 
3956, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
End of stack trace

Is there a setting I'm missing somewhere? My apologies if this is something 
obvious. I did try searching FAQ's etc.

Thanks much,
--Steve

Dave Korn | 1 Aug 17:35 2008

RE: seg fault produces stackdump with no stack trace

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 somewhere? 

  Nah, it probably just means the stack was too badly trashed to backtrace
successfully.  You're probably best off trying it under gdb.

    cheers,
      DaveK
--

-- 
Can't think of a witty .sigline today....

Brian Dessent | 1 Aug 17:46 2008
Picon

Re: seg fault produces stackdump with no stack trace

Steve Waldo wrote:

> but the resulting file contains no stack trace:
> 
> $ cat ResourceMgr.exe.stackdump
> Exception: STATUS_ACCESS_VIOLATION at eip=00000000

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
shouldn't be surprised that this unwinder can't do anything, as this
probably triggers an internal "stop, something's wrong" check because
eip=0 cannot possibly be a correct frame.

The unwinder used here is very primitive, it only knows how to unwind a
standard frame layout.  It does not use anything sophisticated like
unwind tables or debug info, and it will be totally stymied if a frame
uses FPO/-fomit-frame-pointer style optimizations where the return
address is not at 4(%ebp).

Brian

Christopher Faylor | 1 Aug 17:48 2008

Re: seg fault produces stackdump with no stack trace

On Fri, Aug 01, 2008 at 03:24:26PM +0000, 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 stackdump
>file:
>
>[1]-  Segmentation fault      (core dumped) ./ResourceMgr
>
>but the resulting file contains no stack trace:
>
>$ cat ResourceMgr.exe.stackdump 
>Exception: STATUS_ACCESS_VIOLATION at eip=00000000
>eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=611021A0 edi=004026B4
>ebp=0022CC28 esp=0022CC1C program=c:\code\ResourceMgr\ResourceMgr.exe, pid 
>3956, thread main
>cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
>Stack trace:
>Frame     Function  Args
>End of stack trace
>
>Is there a setting I'm missing somewhere?  My apologies if this is
>something obvious.  I did try searching FAQ's etc.

That just means that cygwin's crude stack dump code wasn't able to
figure out a stack dump from the given esp and ebp registers.

Run your program under gdb if you want to really track down the problem.

cgf

(Continue reading)

Steve Waldo | 1 Aug 19:55 2008
Picon

Re: seg fault produces stackdump with no stack trace

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 following message at crash time:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) 

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.

The real crash is occurring too intermittently to catch it in the debugger. 
That's why I was hoping for a stack trace, so I could at least know which 
function to set a breakpoint in.

Thanks again,
--Steve

Brian Dessent | 1 Aug 20:05 2008
Picon

Re: seg fault produces stackdump with no stack trace

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 0x00000000 is because
that is not a valid program location.  But it can give you a backtrace,
you're just not asking for it:

$ gdb --quiet a.exe
(gdb) r
[New thread 2912.0x544]
[New thread 2912.0xaf0]

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x00401052 in letsCrash () at tc.c:4
#2  0x00401083 in main () at tc.c:9
(gdb)

Brian

Dave Korn | 1 Aug 20:08 2008

RE: seg fault produces stackdump with no stack trace

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 .sigline today....


Gmane