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

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
>

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

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.

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

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

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

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.

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

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.

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.