bug in 3.2 configure - Samba

This is a discussion on bug in 3.2 configure - Samba ; The test for realpath is incorrect and causes a core dump at least on FreeBSD and maybe others as well. The following test program is used. The second argument cannot be a NULL (this is what is causing the core). ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: bug in 3.2 configure

  1. bug in 3.2 configure

    The test for realpath is incorrect and causes a core dump at
    least on FreeBSD and maybe others as well.

    The following test program is used. The second argument
    cannot be a NULL (this is what is causing the core).

    #include
    #include
    main() {
    char *newpath = realpath("/tmp", NULL);
    exit ((newpath != NULL) ? 0 : 1);
    }

    Both Linux and FreeBSD show the proto for realpath to be

    char *realpath(const char *path, char *resolved_path);


  2. Re: bug in 3.2 configure

    On Tue, 2008-07-01 at 18:32 -0700, Herb Lewis wrote:
    > The test for realpath is incorrect and causes a core dump at
    > least on FreeBSD and maybe others as well.
    >
    > The following test program is used. The second argument
    > cannot be a NULL (this is what is causing the core).
    >
    > #include
    > #include
    > main() {
    > char *newpath = realpath("/tmp", NULL);
    > exit ((newpath != NULL) ? 0 : 1);
    > }
    >
    > Both Linux and FreeBSD show the proto for realpath to be
    >
    > char *realpath(const char *path, char *resolved_path);


    What is the required allocation size of resolved_path?

    Andrew Bartlett

    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIatyMz4A8Wyi0NrsRAsU+AJ9rs/4+zd1FtuDZXWf10uDc3vUgdQCfSpZR
    0ia1hHEcfEyXZGuKPyW24U4=
    =krzU
    -----END PGP SIGNATURE-----


  3. Re: bug in 3.2 configure

    It is supposed to be MAXPATH size.

    Reading configure a little closer, it looks like we are testing if
    realpath allows a NULL argument.

    Still seems like a bad test if it causes a core dump. Why do we care
    if we can use a NULL?

    Andrew Bartlett wrote:
    > On Tue, 2008-07-01 at 18:32 -0700, Herb Lewis wrote:
    >
    >>The test for realpath is incorrect and causes a core dump at
    >>least on FreeBSD and maybe others as well.
    >>
    >>The following test program is used. The second argument
    >>cannot be a NULL (this is what is causing the core).
    >>
    >>#include
    >>#include
    >>main() {
    >> char *newpath = realpath("/tmp", NULL);
    >> exit ((newpath != NULL) ? 0 : 1);
    >>}
    >>
    >>Both Linux and FreeBSD show the proto for realpath to be
    >>
    >>char *realpath(const char *path, char *resolved_path);

    >
    >
    > What is the required allocation size of resolved_path?
    >
    > Andrew Bartlett
    >



  4. Re: bug in 3.2 configure

    On Tue, 2008-07-01 at 18:47 -0700, Herb Lewis wrote:
    > It is supposed to be MAXPATH size.
    >
    > Reading configure a little closer, it looks like we are testing if
    > realpath allows a NULL argument.
    >
    > Still seems like a bad test if it causes a core dump. Why do we care
    > if we can use a NULL?


    Presumably, because if we can use NULL then we don't have to use a
    pstring, and Samba 3.2 declared war on pstrings, in favour of totally
    dynamic memory allocation.

    Andrew Bartlett
    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIat9Wz4A8Wyi0NrsRAnXiAKCEhZJFkyAdQ0mZOKWz+n 6uRnCcLwCgsl/S
    ENSDx1EmRZ59uU5tE/csGWk=
    =6Xam
    -----END PGP SIGNATURE-----


  5. Re: bug in 3.2 configure

    On Tue, Jul 01, 2008 at 06:47:08PM -0700, Herb Lewis wrote:
    > It is supposed to be MAXPATH size.
    >
    > Reading configure a little closer, it looks like we are testing if
    > realpath allows a NULL argument.
    >
    > Still seems like a bad test if it causes a core dump. Why do we care
    > if we can use a NULL?


    >From the linux glibc man pages for realpath :


    The glibc implementation of realpath() provides a non-standard
    extension. If resolved_path is specified as NULL, then realpath() uses
    mal-
    loc(3) to allocate a buffer of up to PATH_MAX bytes to hold the
    resolved pathname, and returns a pointer to this buffer. The caller
    should
    deallocate this buffer using free(3).

    This is very useful, and we have a code path to use it.

    Jeremy.


  6. Re: bug in 3.2 configure

    On Wed, Jul 2, 2008 at 7:27 PM, Jeremy Allison wrote:
    > On Tue, Jul 01, 2008 at 06:47:08PM -0700, Herb Lewis wrote:
    >> It is supposed to be MAXPATH size.
    >>
    >> Reading configure a little closer, it looks like we are testing if
    >> realpath allows a NULL argument.
    >>
    >> Still seems like a bad test if it causes a core dump. Why do we care
    >> if we can use a NULL?

    >
    > This is very useful, and we have a code path to use it.


    Personally, I see no problem with core dumps in the configure tests,
    as soon as they don't collapes the whole box

    With best regards,
    Timur


  7. Re: bug in 3.2 configure

    On Thu, 2008-07-03 at 03:43 +0200, Timur I. Bakeyev wrote:
    > On Wed, Jul 2, 2008 at 7:27 PM, Jeremy Allison wrote:
    > > On Tue, Jul 01, 2008 at 06:47:08PM -0700, Herb Lewis wrote:
    > >> It is supposed to be MAXPATH size.
    > >>
    > >> Reading configure a little closer, it looks like we are testing if
    > >> realpath allows a NULL argument.
    > >>
    > >> Still seems like a bad test if it causes a core dump. Why do we care
    > >> if we can use a NULL?

    > >
    > > This is very useful, and we have a code path to use it.

    >
    > Personally, I see no problem with core dumps in the configure tests,
    > as soon as they don't collapes the whole box


    We have avoided them in the past, when a non-coredump test would
    indicate the same result, but adding a signal handler to a configure
    test would seem overkill...

    Andrew Bartlett
    --
    Andrew Bartlett
    http://samba.org/~abartlet/
    Authentication Developer, Samba Team http://samba.org
    Samba Developer, Red Hat Inc.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQBIdb4Wz4A8Wyi0NrsRAgOgAJ93vd4nhHbfVPB5t9x5xK JYZ+KORgCggjX7
    kiJKDoGZkp5PMZXMN/DyeV4=
    =IM7u
    -----END PGP SIGNATURE-----


  8. RE: bug in 3.2 configure

    > -----Original Message-----
    > From: Andrew Bartlett
    > Sent: Thursday, July 10, 2008 12:45 AM
    >
    > On Thu, 2008-07-03 at 03:43 +0200, Timur I. Bakeyev wrote:
    > > On Wed, Jul 2, 2008 at 7:27 PM, Jeremy Allison

    wrote:
    > > > On Tue, Jul 01, 2008 at 06:47:08PM -0700, Herb Lewis wrote:
    > > >> It is supposed to be MAXPATH size.
    > > >>
    > > >> Reading configure a little closer, it looks like we are testing

    if
    > > >> realpath allows a NULL argument.
    > > >>
    > > >> Still seems like a bad test if it causes a core dump. Why do we

    care
    > > >> if we can use a NULL?
    > > >
    > > > This is very useful, and we have a code path to use it.

    > >
    > > Personally, I see no problem with core dumps in the configure tests,
    > > as soon as they don't collapes the whole box

    >
    > We have avoided them in the past, when a non-coredump test would
    > indicate the same result, but adding a signal handler to a configure
    > test would seem overkill...


    I'll probably patch it later today and submit something. Core files on
    our system end up in /var/crash (rather than the execution directory),
    and people get tetchy when random cores appear.

    ....Zach


  9. Re: [PATCH] Fix realpath() check so that it doesn't generate acore() when it fails

    On Thu, Jul 10, 2008 at 01:33:04PM -0700, Zachary Loafman wrote:
    > > I'll probably patch it later today and submit something. Core files on

    > our
    > > system end up in /var/crash (rather than the execution directory), and
    > > people get tetchy when random cores appear.


    Pushed, thanks !

    Jeremy.


  10. Re: [PATCH] Fix realpath() check so that it doesn't generate acore() when it fails

    On Thu, Jul 10, 2008 at 03:26:26PM -0700, Jeremy Allison wrote:
    > On Thu, Jul 10, 2008 at 01:33:04PM -0700, Zachary Loafman wrote:
    > > > I'll probably patch it later today and submit something. Core files on

    > > our
    > > > system end up in /var/crash (rather than the execution directory), and
    > > > people get tetchy when random cores appear.

    >
    > Pushed, thanks !


    Jeremy, at one point you need to look at "git am -3" :-)

    Volker

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)

    iD8DBQFIdv5GUzqjrWwMRl0RAm4xAJ9rnwWwcGlqGGs/L34BV3pQM3ECLgCfa+V6
    eYnwhN96274OzQM4iMua1jM=
    =6BhF
    -----END PGP SIGNATURE-----


  11. Re: [PATCH] Fix realpath() check so that it doesn't generate acore() when it fails

    On Fri, Jul 11, 2008 at 08:31:35AM +0200, Volker Lendecke wrote:
    > On Thu, Jul 10, 2008 at 03:26:26PM -0700, Jeremy Allison wrote:
    > > On Thu, Jul 10, 2008 at 01:33:04PM -0700, Zachary Loafman wrote:
    > > > > I'll probably patch it later today and submit something. Core files on
    > > > our
    > > > > system end up in /var/crash (rather than the execution directory), and
    > > > > people get tetchy when random cores appear.

    > >
    > > Pushed, thanks !

    >
    > Jeremy, at one point you need to look at "git am -3" :-)


    I used git-am to merge it. What does git-am -3 do ?

    Jeremy.


  12. Re: [PATCH] Fix realpath() check so that it doesn't generate acore() when it fails

    On Fri, 2008-07-11 at 09:10 -0700, Jeremy Allison wrote:
    > On Fri, Jul 11, 2008 at 08:31:35AM +0200, Volker Lendecke wrote:
    > > On Thu, Jul 10, 2008 at 03:26:26PM -0700, Jeremy Allison wrote:
    > > > On Thu, Jul 10, 2008 at 01:33:04PM -0700, Zachary Loafman wrote:
    > > > > > I'll probably patch it later today and submit something. Core files on
    > > > > our
    > > > > > system end up in /var/crash (rather than the execution directory), and
    > > > > > people get tetchy when random cores appear.
    > > >
    > > > Pushed, thanks !

    > >
    > > Jeremy, at one point you need to look at "git am -3" :-)

    >
    > I used git-am to merge it. What does git-am -3 do ?


    -3, --3way
    When the patch does not apply cleanly, fall back on 3-way merge, if
    the patch records the identity of blobs it is supposed to apply to,
    and we have those blobs available locally.

    I guess to have a clean merge ?
    Never tried it, but looks very interesting.

    Simo.

    --
    Simo Sorce
    Samba Team GPL Compliance Officer
    Senior Software Engineer at Red Hat Inc.


+ Reply to Thread