similar crash in mmap for 1.5.3-1

similar crash in mmap for 1.5.3-1

[John Joganic]

Previous posts described a bug in mmap called via malloc. I am seeing a 
bug in mmap itself.  The following test does not map large amounts of 
memory, nor does it leak.  It crashes however, after 4193 (0x1061) 
iterations every time.  Like the malloc crash, the call stack references 
strdup, and in this case calloc as well.  On a Linux box, this program 
runs to completion without a hitch.

Thanks!

-John

fail.c:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>

int main(int argc, char **argv)
{
        int i, fd;
        void *p;
        char buf[1024] = { 0 };

        fd = open("test.dat",O_CREAT|O_RDWR,0666);
        if (fd < 0) { perror("failed to open"); exit(1); }
        write(fd,buf,1024);

        for (i=0; i<10000; ++i)
        {
                fprintf(stderr,"%d ",i);
                p = mmap(NULL,1024,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
                if (!p) { perror("failed mmap"); exit(1); }
                fprintf(stderr,"=> %p\n",p);
                munmap(p,1024);
        }

        printf("success\n");
        close(fd);
        return 0;
}

The result is:

...
4186 => 0x3f0000
4187 => 0x3f0000
4188 => 0x3f0000
4189 => 0x3f0000
4190 => 0x3f0000
4191 => 0x3f0000
4192 => 0x3f0000
4193       4 [main] fail 3024 cmalloc: cmalloc returned NULL

Program received signal SIGSEGV, Segmentation fault.
0x6103f1d9 in strdup () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x6103f1d9 in strdup () from /usr/bin/cygwin1.dll
#1  0x6103fcc2 in mmap64 () from /usr/bin/cygwin1.dll
#2  0x004011d6 in main ()
(gdb)



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: similar crash in mmap for 1.5.3-1

[Christopher Faylor]

On Mon, Sep 08, 2003 at 03:31:31PM -0700, John Joganic wrote:
>Previous posts described a bug in mmap called via malloc. I am seeing a 
>bug in mmap itself.  The following test does not map large amounts of 
>memory, nor does it leak.  It crashes however, after 4193 (0x1061) 
>iterations every time.  Like the malloc crash, the call stack references 
>strdup, and in this case calloc as well.  On a Linux box, this program 
>runs to completion without a hitch.

I guess I have to point this out every single time someone mentions
strdup.  mmap does not call strdup.  You can't get a reliable crash dump
from a stripped DLL, which cygwin1.dll is, of course.  I can't believe
that this has to be a FAQ entry but apparently it does.

If you want to help with a back trace, you have to build your own version
of the DLL with debugging symbols.

Is this clear everyone?  Do you get it, all of you future archive
spelunkers?  No more mentions of strdup and mmap.  No more backtraces
with of an unstripped cygwin DLL.  The only thing that shows us is that
the crash occurred in the DLL itself and we would get that from the *.stackdump
file.

As long as we're at it, you might want to check out http://cygwin.com/problems.html .
Simple test cases are a godsend but so is information from cygcheck.exe.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: similar crash in mmap for 1.5.3-1

[Corinna Vinschen]

On Mon, Sep 08, 2003 at 03:31:31PM -0700, John Joganic wrote:
> Previous posts described a bug in mmap called via malloc. I am seeing a 
> bug in mmap itself.  The following test does not map large amounts of 
> memory, nor does it leak.  It crashes however, after 4193 (0x1061) 
> iterations every time.  Like the malloc crash, the call stack references 
> strdup, and in this case calloc as well.  On a Linux box, this program 
> runs to completion without a hitch.

This has been fixed a few days ago.  Try a recent snapshot.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Hannu E K Nevalainen (garbage mail)]

> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor

<SNIP>
> ... You can't get a reliable crash dump
> from a stripped DLL, which cygwin1.dll is, of course.  I can't believe
> that this has to be a FAQ entry but apparently it does.
>
> If you want to help with a back trace, you have to build your own version
> of the DLL with debugging symbols.

Idea, to help debug things like the above:

 Alt 1) Make an _unstripped_ cygwin1.dll available in a package named
        "cygwin-DEBUG-dll" or some such. Also make it be "TEST/Exp" forever.
 Alt 2) Have an unstripped cygwin1-DEBUG.dll added to the basic package,
        add a simple "cygswapdll" utility.

Is this a Good or Bad idea?

/Hannu E K Nevalainen, B.Sc. EE - 59?16.37'N, 17?12.60'E
--END OF MESSAGE--


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Christopher Faylor]

On Tue, Sep 09, 2003 at 10:41:46AM +0200, Hannu E K Nevalainen (garbage mail) wrote:
>> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
>> Of Christopher Faylor
>
><SNIP>
>> ... You can't get a reliable crash dump
>> from a stripped DLL, which cygwin1.dll is, of course.  I can't believe
>> that this has to be a FAQ entry but apparently it does.
>>
>> If you want to help with a back trace, you have to build your own version
>> of the DLL with debugging symbols.
>
>Idea, to help debug things like the above:
>
> Alt 1) Make an _unstripped_ cygwin1.dll available in a package named
>        "cygwin-DEBUG-dll" or some such. Also make it be "TEST/Exp" forever.
> Alt 2) Have an unstripped cygwin1-DEBUG.dll added to the basic package,
>        add a simple "cygswapdll" utility.
>
>Is this a Good or Bad idea?

The new version of binutils allows you to strip debug information and put
it in a separate file. Then you can provide that file to gdb and use it
for debugging.

If I was going to do anything, that is what I would do.  I'd just provide
the debug info for the released binaries.  This is one of the reasons why
I uploaded a new binutils and gdb recently, in fact.

However, like everything there are two problems 1) lack of tuit cycles and
2) it won't stop people from running gdb on their binaries and reporting
that strdup is causing a problem in mmap.  There will still be a "download
the debug info" step no matter what.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Hannu E K Nevalainen (garbage mail)]

> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor

<SNIP>
> >Idea, to help debug things like the above:
> >
> > Alt 1) Make an _unstripped_ cygwin1.dll available in a package named
> >        "cygwin-DEBUG-dll" or some such. Also make it be
> "TEST/Exp" forever.
> > Alt 2) Have an unstripped cygwin1-DEBUG.dll added to the basic package,
> >        add a simple "cygswapdll" utility.
> >
> >Is this a Good or Bad idea?
>
> The new version of binutils allows you to strip debug information and put
> it in a separate file. Then you can provide that file to gdb and use it
> for debugging.

 Right, now that you mention it I remember seeing it. My ideas ran obsolete
already in the start ':-> .

> However, like everything there are two problems 1) lack of tuit cycles and
> 2) it won't stop people from running gdb on their binaries and reporting
> that strdup is causing a problem in mmap.  There will still be a "download
> the debug info" step no matter what.
>
> cgf

 Most likely... Some wording regarding "download the debug info" needs to be
added to "problems.html" - I guess.

/Hannu E K Nevalainen, B.Sc. EE - 59?16.37'N, 17?12.60'E
--END OF MESSAGE--


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Christopher Faylor]

On Wed, Sep 10, 2003 at 01:23:56PM +0200, Hannu E K Nevalainen (garbage mail) wrote:
>> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
>> Of Christopher Faylor
>
><SNIP>
>> >Idea, to help debug things like the above:
>> >
>> > Alt 1) Make an _unstripped_ cygwin1.dll available in a package named
>> >        "cygwin-DEBUG-dll" or some such. Also make it be
>> "TEST/Exp" forever.
>> > Alt 2) Have an unstripped cygwin1-DEBUG.dll added to the basic package,
>> >        add a simple "cygswapdll" utility.
>> >
>> >Is this a Good or Bad idea?
>>
>> The new version of binutils allows you to strip debug information and put
>> it in a separate file. Then you can provide that file to gdb and use it
>> for debugging.
>
> Right, now that you mention it I remember seeing it. My ideas ran obsolete
>already in the start ':-> .
>
>> However, like everything there are two problems 1) lack of tuit cycles and
>> 2) it won't stop people from running gdb on their binaries and reporting
>> that strdup is causing a problem in mmap.  There will still be a "download
>> the debug info" step no matter what.
>
> Most likely... Some wording regarding "download the debug info" needs to be
>added to "problems.html" - I guess.

That sort of presupposes that someone is interested in walking people through
the debugging of the cygwin DLL.  I know I'm not interested and I haven't
seen anyone else step in when people start asking debugging questions.

I guess the words in problems.html could be extended with a "You're basically
on your own"...

This is not a bad idea, especially since I thought of it myself long ago :-),
like I said, it just requires some time which I don't have right now.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Igor Pechtchanski]

On Wed, 10 Sep 2003, Christopher Faylor wrote:

> On Wed, Sep 10, 2003 at 01:23:56PM +0200, Hannu E K Nevalainen (garbage mail) wrote:
> >> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> >> Of Christopher Faylor
> >
> ><SNIP>
> >> >Idea, to help debug things like the above:
> >> >
> >> > Alt 1) Make an _unstripped_ cygwin1.dll available in a package named
> >> >        "cygwin-DEBUG-dll" or some such. Also make it be
> >> "TEST/Exp" forever.
> >> > Alt 2) Have an unstripped cygwin1-DEBUG.dll added to the basic package,
> >> >        add a simple "cygswapdll" utility.
> >> >
> >> >Is this a Good or Bad idea?
> >>
> >> The new version of binutils allows you to strip debug information and put
> >> it in a separate file. Then you can provide that file to gdb and use it
> >> for debugging.
> >
> > Right, now that you mention it I remember seeing it. My ideas ran obsolete
> >already in the start ':-> .
> >
> >> However, like everything there are two problems 1) lack of tuit cycles and
> >> 2) it won't stop people from running gdb on their binaries and reporting
> >> that strdup is causing a problem in mmap.  There will still be a "download
> >> the debug info" step no matter what.
> >
> > Most likely... Some wording regarding "download the debug info" needs to be
> >added to "problems.html" - I guess.
>
> That sort of presupposes that someone is interested in walking people through
> the debugging of the cygwin DLL.  I know I'm not interested and I haven't
> seen anyone else step in when people start asking debugging questions.
>
> I guess the words in problems.html could be extended with a "You're basically
> on your own"...
>
> This is not a bad idea, especially since I thought of it myself long ago :-),
> like I said, it just requires some time which I don't have right now.
>
> cgf

FWIW, I think Hannu has a point in that if debugging information were
available, it would be much easier for people to step in and outline the
necessary actions to provide a good stack trace than it would be to show
them how to build a debug version of the DLL from scratch.  Just my 2c.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Christopher Faylor]

On Wed, Sep 10, 2003 at 11:40:33AM -0400, Igor Pechtchanski wrote:
>On Wed, 10 Sep 2003, Christopher Faylor wrote:
>>On Wed, Sep 10, 2003 at 01:23:56PM +0200, Hannu E K Nevalainen (garbage mail) wrote:
>>>>From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
>>>>Of Christopher Faylor
>>>
>>><SNIP>
>>>>>Idea, to help debug things like the above:
>>>>>
>>>>>Alt 1) Make an _unstripped_ cygwin1.dll available in a package named
>>>>>"cygwin-DEBUG-dll" or some such.  Also make it be
>>>>"TEST/Exp" forever.
>>>>>Alt 2) Have an unstripped cygwin1-DEBUG.dll added to the basic package,
>>>>>add a simple "cygswapdll" utility.
>>>>>
>>>>>Is this a Good or Bad idea?
>>>>
>>>>The new version of binutils allows you to strip debug information and
>>>>put it in a separate file.  Then you can provide that file to gdb and
>>>>use it for debugging.
>>>
>>>Right, now that you mention it I remember seeing it.  My ideas ran
>>>obsolete already in the start ':-> .
>>>
>>>>However, like everything there are two problems 1) lack of tuit cycles
>>>>and 2) it won't stop people from running gdb on their binaries and
>>>>reporting that strdup is causing a problem in mmap.  There will still
>>>>be a "download the debug info" step no matter what.
>>>
>>>Most likely...  Some wording regarding "download the debug info" needs
>>>to be added to "problems.html" - I guess.
>>
>>That sort of presupposes that someone is interested in walking people
>>through the debugging of the cygwin DLL.  I know I'm not interested and
>>I haven't seen anyone else step in when people start asking debugging
>>questions.
>>
>>I guess the words in problems.html could be extended with a "You're
>>basically on your own"...
>>
>>This is not a bad idea, especially since I thought of it myself long
>>ago :-), like I said, it just requires some time which I don't have
>>right now.
>
>FWIW, I think Hannu has a point in that if debugging information were
>available, it would be much easier for people to step in and outline
>the necessary actions to provide a good stack trace than it would be to
>show them how to build a debug version of the DLL from scratch.  Just
>my 2c.

"This is not a bad idea...it just requires some time which I don't have
right now."

I haven't, so far, seen anyone chime in usefully on this issue when
people have provided stack traces.  There are other issues which would
crop up even if debugging info were available like the fact that traces
are unreliable where they include functions without stack frame info.

Also, the problems.html page is surely the wrong place for a tutorial
for how to debug the cygwin DLL.  A hyperlink to a page which talked
about this, with a caveat about this being only for the technically
savvy, would be fine.  But I'm not going to write it.  Volunteers?
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Hannu E K Nevalainen (garbage mail)]

<SNIP>
Hannu:
> >>>Most likely...  Some wording regarding "download the debug info" needs
> >>>to be added to "problems.html" - I guess.
> >>

CGF:
> >>That sort of presupposes that someone is interested in walking people
> >>through the debugging of the cygwin DLL.  I know I'm not interested and
> >>I haven't seen anyone else step in when people start asking debugging
> >>questions.
> >>
> >>I guess the words in problems.html could be extended with a "You're
> >>basically on your own"...

 Indeed... with some more words that points to useful information... or?

> >>This is not a bad idea, especially since I thought of it myself long
> >>ago :-), like I said, it just requires some time which I don't have
> >>right now.

 :-) ...have I heard those words before? Have I spoken in the same manner
myself? ;-)

> >FWIW, I think Hannu has a point in that if debugging information were
> >available, it would be much easier for people to step in and outline
> >the necessary actions to provide a good stack trace than it would be to
> >show them how to build a debug version of the DLL from scratch.  Just
> >my 2c.
>
> "This is not a bad idea...it just requires some time which I don't have
> right now."
>
> I haven't, so far, seen anyone chime in usefully on this issue when
> people have provided stack traces.  There are other issues which would
> crop up even if debugging info were available like the fact that traces
> are unreliable where they include functions without stack frame info.
>
> Also, the problems.html page is surely the wrong place for a tutorial
> for how to debug the cygwin DLL.  A hyperlink to a page which talked
> about this, with a caveat about this being only for the technically
> savvy, would be fine.  But I'm not going to write it.  Volunteers?

 Well, there needn't be a _tutorial_ on debugging. Maybe just a link to a
good starting point for understanding gdb/ddd/insight and their usage - for
beginners [1].
 Non-beginners often need just a few words... these words should be added
though - time permitting, as always.

/Hannu E K Nevalainen, B.Sc. EE - 59?16.37'N, 17?12.60'E

--
[1]
 I've been investigating AmigaOS executables _thoroughly_ and thus know that
some stuff do require intimate knowledge of OS internals.

--END OF MESSAGE--


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Christopher Faylor]

On Wed, Sep 10, 2003 at 10:27:10PM +0200, Hannu E K Nevalainen (garbage mail) wrote:
>> Also, the problems.html page is surely the wrong place for a tutorial
>> for how to debug the cygwin DLL.  A hyperlink to a page which talked
>> about this, with a caveat about this being only for the technically
>> savvy, would be fine.  But I'm not going to write it.  Volunteers?
>
> Well, there needn't be a _tutorial_ on debugging. Maybe just a link to a
>good starting point for understanding gdb/ddd/insight and their usage - for
>beginners [1].
> Non-beginners often need just a few words... these words should be added
>though - time permitting, as always.

I think you are missing my point.  I do not want a problems page to be
littered with a "and here's how you debug cygwin" or here's where to
find debuggers.  That would be daunting to people who are already
daunted by the amount of info on that page.  A hyperlink with something
like:

- Consider <a href="debugcygwin.html">debugging cygwin</a> yourself or
  possibly <a href="debugcygwin.html#backtrace">providing a back trace</a>
  of a failing application.

I have a fundamental problem with adding tutorials on debugging here.
Go to the gdb page if you want to learn how to debug something.  A
(very) few pointers on how to debug with a DLL are fine, since they
would be cygwin-specific.  But info on setting breakpoints, etc., really
should come from the experts.

I'm also *extremely* dubious that we'd get useful information from someone
who has never heard of a debugger or even someone who hasn't heard about
gdb.

Anyway, as usual, we're discussing something that will probably never
happen.  I'm finished now since I've already used up too much time
reiterating points.  My next act will be to review any documentation
provided.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Hannu E K Nevalainen (garbage mail)]

> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor

> On Wed, Sep 10, 2003 at 10:27:10PM +0200, Hannu E K Nevalainen
> (garbage mail) wrote:
> >> Also, the problems.html page is surely the wrong place for a tutorial
> >> for how to debug the cygwin DLL.  A hyperlink to a page which talked
> >> about this, with a caveat about this being only for the technically
> >> savvy, would be fine.  But I'm not going to write it.  Volunteers?
> >
> > Well, there needn't be a _tutorial_ on debugging. Maybe just a link to a
> >good starting point for understanding gdb/ddd/insight and their
> usage - for
> >beginners [1].
> > Non-beginners often need just a few words... these words should be added
> >though - time permitting, as always.
>
> I think you are missing my point.  I do not want a problems page to be
> littered with a "and here's how you debug cygwin" or here's where to
> find debuggers.  That would be daunting to people who are already
> daunted by the amount of info on that page.  A hyperlink with something
> like:
>
> - Consider <a href="debugcygwin.html">debugging cygwin</a> yourself or
>   possibly <a href="debugcygwin.html#backtrace">providing a back trace</a>
>   of a failing application.

 This seems be about what I had in mind, a bit depending on what
"debugcygwin.html" would contain.

> I have a fundamental problem with adding tutorials on debugging here.
> Go to the gdb page if you want to learn how to debug something.  A
> (very) few pointers on how to debug with a DLL are fine, since they
> would be cygwin-specific.  But info on setting breakpoints, etc., really
> should come from the experts.

 As I said above; _no_ tutorials, but pointers to good _starting points_ for
"beginners" - i.e. one or more ways to find out more on the matter.

> I'm also *extremely* dubious that we'd get useful information from someone
> who has never heard of a debugger or even someone who hasn't heard about
> gdb.

 This depends on what you evaluate the word "beginner" to...
 1) a beginner with debugging all together; then you're fully correct above
 2) a beginner with cygwin; the above might not be so "correct" anymore
 3) (more?)

 I put myself would fit in category 2) of two reasons; I have not used gdb
or its siblings for major stuff, nor tried to debug cygwin stuff. But I DO
have debugging experience.

> Anyway, as usual, we're discussing something that will probably never
> happen.

 ..and you have found this "time consuming" only? ;-)  (I hope not)

>  I'm finished now since I've already used up too much time
> reiterating points.  My next act will be to review any documentation
> provided.

 Fine with me :-)

/Hannu E K Nevalainen, B.Sc. EE - 59?16.37'N, 17?12.60'E
--END OF MESSAGE--


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/