Re: mp4h: Strange? segfault problem

[Svante Signell]

On Wed, 2011-12-28 at 10:33 +0100, Samuel Thibault wrote:
> Svante Signell, le Wed 28 Dec 2011 10:17:24 +0100, a écrit :
> > On GNU/Linux shortening the resolvedname vector from PATH_MAX to 64
> > results in a stack corruption. This is not nice, but since that vector
> > is allocated on the stack, maybe it is more acceptable than an
> > environment corruption. 
> 
> Well, this is not surprising to get crashes when cheating with PATH_MAX:
> the kernel still thinks PATH_MAX is 4096, and thus thinks that the
> buffer is actually 4096 bytes long, and thus happily overwrites whatever
> is after it if userland doesn't make it so.

Ok, this comparison was maybe not the best. The main problem remains,
for Hurd, how can a too short path string overwrite the environment
vector of strings? I tried to find instances where __environment is
used/set and found only references to eglibc, not gnumach or hurd. I
also compiled a version of libc with printf statements and used gdb, but
nothing usable showed yet. I will try to create a shorter test case than
the whole mp4h executable. Any hints on where to look for further
debugging?