On Wed, 2017-09-27 at 17:56 +0200, Samuel Thibault wrote:
> Samuel Thibault, on mer. 27 sept. 2017 14:53:18 +0200, wrote:
> > Svante Signell, on mer. 27 sept. 2017 11:43:34 +0200, wrote:
> > > What else did you find?
> >
> > That was mostly that, exactly :)
> >
> > Plus symbol exposition and an
Samuel Thibault, on mer. 27 sept. 2017 14:53:18 +0200, wrote:
> Svante Signell, on mer. 27 sept. 2017 11:43:34 +0200, wrote:
> > What else did you find?
>
> That was mostly that, exactly :)
>
> Plus symbol exposition and an issue with absolute paths, commit to come
> soon.
Now it's committed,
Svante Signell, on mer. 27 sept. 2017 11:43:34 +0200, wrote:
> What else did you find?
That was mostly that, exactly :)
Plus symbol exposition and an issue with absolute paths, commit to come
soon.
Samuel
On Tue, 2017-09-26 at 22:07 +0200, Samuel Thibault wrote:
> Hello,
>
> This time it looks correct :)
>
> (just a couple of nitpicks which I'll just fix).
I saw that I forgot to free (cwd) immediately in execve.c. Do you want an
updated patch? Additionally I wrote in spawni.c:
/* Absolute path
Hello,
This time it looks correct :)
(just a couple of nitpicks which I'll just fix).
Samuel
On Tue, 2017-09-26 at 16:24 +0200, Samuel Thibault wrote:
> That should be “filename” instead of “file”.
Yes of course. That was merely a copy/paste error. Thanks for finding it.
> Take the case of PATH containing e.g. :bin: , and your current directory
> contains a bin directory which contains
Svante Signell, on mar. 26 sept. 2017 16:15:06 +0200, wrote:
> + /* Relative path */
> + else
> + {
> + cwd = getcwd (NULL, 0);
> + if (cwd == NULL)
> + goto out;
> +
> + res = asprintf (_name, "%s/%s", cwd, file);
That should be
On Mon, 2017-09-25 at 18:01 +0200, Samuel Thibault wrote:
> Svante Signell, on lun. 25 sept. 2017 17:51:52 +0200, wrote:
> > The following tests still reveal unwanted behaviour: (where to change ?)
These two tests are now OK.
> It's in the PATH lookup case, just below where you added your code.
Svante Signell, on lun. 25 sept. 2017 17:51:52 +0200, wrote:
> However child_lookup() expects a const char *, but the compiler does not
> complain here.
Sure, you can pass a char* to a function that expects a const char*.
> The following tests still reveal unwanted behaviour: (where to change ?)
On Sun, 2017-09-24 at 15:58 +0200, Svante Signell wrote:
> On Sun, 2017-09-24 at 15:22 +0200, Samuel Thibault wrote:
> > Hello,
> >
> > Svante Signell, on dim. 24 sept. 2017 15:17:02 +0200, wrote:
> > > On Fri, 2017-09-22 at 20:27 +0200, Samuel Thibault wrote:
> > I however realize: we of course
On Sun, 2017-09-24 at 15:22 +0200, Samuel Thibault wrote:
> Hello,
>
> Svante Signell, on dim. 24 sept. 2017 15:17:02 +0200, wrote:
> > On Fri, 2017-09-22 at 20:27 +0200, Samuel Thibault wrote:
> I however realize: we of course need the same for spawni() (using
> getcwd
> instead of realpath),
Hello,
Svante Signell, on dim. 24 sept. 2017 15:17:02 +0200, wrote:
> On Fri, 2017-09-22 at 20:27 +0200, Samuel Thibault wrote:
> > Hello,
> >
> > > + file_t file = __file_name_lookup (file_name, O_EXEC, 0);
> >
> > This creates a file_t, so return paths have to deallocate it (just
> > like it
On Fri, 2017-09-22 at 20:27 +0200, Samuel Thibault wrote:
> Hello,
>
> > + file_t file = __file_name_lookup (file_name, O_EXEC, 0);
>
> This creates a file_t, so return paths have to deallocate it (just
> like it is done at the end of the function).
Fixed.
> Along the way, you could move the
Hello,
Svante Signell, on ven. 22 sept. 2017 16:24:11 +0200, wrote:
> Final version?
Almost there :)
> -/* Replace the current process, executing FILE_NAME with arguments ARGV and
> - environment ENVP. ARGV and ENVP are terminated by NULL pointers. */
> +/* Replace the current process,
On Thu, 2017-09-21 at 14:46 +0200, Samuel Thibault wrote:
> Svante Signell, on jeu. 21 sept. 2017 10:11:42 +0200, wrote:
> > Sorry. Now I've built glibc successfully.
> > Should this warning be fixed with a cast too?
>
> Casting is almost never the right solution.
>
> And here it's for a good
Svante Signell, on jeu. 21 sept. 2017 10:11:42 +0200, wrote:
> Sorry. Now I've built glibc successfully.
> Should this warning be fixed with a cast too?
Casting is almost never the right solution.
And here it's for a good reason: file_name is not to be modified, or
more importantly, freed. You
On Thu, 2017-09-21 at 09:39 +0200, Svante Signell wrote:
> On Thu, 2017-09-21 at 01:01 +0200, Samuel Thibault wrote:
> > Svante Signell, on mer. 20 sept. 2017 08:46:49 +0200, wrote:
> > > I changed the patch for __execve() to keep file_name if the path is
> > > absolute
> > > and
> > > call
On Thu, 2017-09-21 at 01:01 +0200, Samuel Thibault wrote:
> Svante Signell, on mer. 20 sept. 2017 08:46:49 +0200, wrote:
> > I changed the patch for __execve() to keep file_name if the path is absolute
> > and
> > call realpath() for relative paths.
>
> But then if you call a script that looks at
Svante Signell, on mer. 20 sept. 2017 08:46:49 +0200, wrote:
> I changed the patch for __execve() to keep file_name if the path is absolute
> and
> call realpath() for relative paths.
But then if you call a script that looks at $0 from a relative path,
it'll break.
> (I did also a cetcwd()
On Mon, 2017-09-18 at 20:56 +0200, Samuel Thibault wrote:
> Svante Signell, on lun. 18 sept. 2017 19:45:39 +0200, wrote:
> > lrwxr-xr-x 1 root root 26 Aug 17 07:38 /usr/sbin/update-fmtutil -> update-
> > tl-
> > stacked-conffile
> >
> > In this case the link name should not be resolved. Any
(good catch, btw :) )
Samuel
Svante Signell, on lun. 18 sept. 2017 19:45:39 +0200, wrote:
> lrwxr-xr-x 1 root root 26 Aug 17 07:38 /usr/sbin/update-fmtutil -> update-tl-
> stacked-conffile
>
> In this case the link name should not be resolved. Any ideas?
Well, it should, but just not the symlink parts, only the cwd part.
On Sun, 2017-09-17 at 20:27 +0200, Samuel Thibault wrote:
> Hello,
>
> Svante Signell, on ven. 15 sept. 2017 14:09:05 +0200, wrote:
> > Patch updated:
>
> This looks good, I'll commit that, thanks!
Sadly I found a bug with the current implementation for shell scripts:
ls -l
Hello,
Svante Signell, on ven. 15 sept. 2017 14:09:05 +0200, wrote:
> Patch updated:
This looks good, I'll commit that, thanks!
Samuel
On Fri, 2017-09-15 at 13:20 +0200, Samuel Thibault wrote:
> Hello,
>
> Svante Signell, on ven. 15 sept. 2017 12:35:56 +0200, wrote:
> > > > ++ file_t file = __file_name_lookup (filename, O_EXEC, 0);
> Still, the question becomes: better use file_name instead of
> abs_path, because file_name
Hello,
Svante Signell, on ven. 15 sept. 2017 12:35:56 +0200, wrote:
> > > ++ file_t file = __file_name_lookup (filename, O_EXEC, 0);
> >
> > Why doing this?
>
> This is part of the original code. diff of *.diff files confused again?
Ah, indeed, sorry. A diff of diff is not the easiest thing
On Fri, 2017-09-15 at 01:49 +0200, Samuel Thibault wrote:
> Well, rather avoid having a 'filename' variable along the 'file_name'
> variable, that's confusing :)
>
> Better calling absolute_path for instance.
I named it abs_path.
> > ++ file_t file = __file_name_lookup (filename, O_EXEC, 0);
Svante Signell, on lun. 11 sept. 2017 12:19:35 +0200, wrote:
> > This is another bug in the backtrace. hex2dec('deadbeef')/1024^3 = 3.4794
> > GiB
> > Even if the address is outside the gnumach range, the program should not
> > fail
> > with a SIGILL. Or?
>
> Any ideas why the signal is SIGILL
Svante Signell, on jeu. 14 sept. 2017 14:10:05 +0200, wrote:
> With the updated patch things works fine:
Cool :)
> + __execve (const char *file_name, char *const argv[], char *const envp[])
> + {
> + error_t err;
> +- file_t file = __file_name_lookup (file_name, O_EXEC, 0);
> +
> +- if
On Mon, 2017-09-11 at 10:52 +0200, Svante Signell wrote:
> On Sat, 2017-09-09 at 22:04 +0200, Samuel Thibault wrote:
> > Svante Signell, on sam. 09 sept. 2017 10:51:36 +0200, wrote:
> > >
> > Which programs do you run?
> >
> > execv/spawn are called from the parent, so the program that needs
> >
On Thu, 2017-09-07 at 10:38 +0200, Svante Signell wrote:
>
> 2) test_sighandler.c:
>
> GNU/Linux:
> ./test_sighandler
> Got signal 11, faulty address is 0xdeadbeef, from 5597bd471de0
> Executable name = '/home/srs/Hurd/DEBs/test_cases/test_sighandler�', len = 47
> [bt] Execution path:
> [bt]
On Sat, 2017-09-09 at 22:04 +0200, Samuel Thibault wrote:
> Svante Signell, on sam. 09 sept. 2017 10:51:36 +0200, wrote:
> > On Fri, 2017-09-08 at 00:39 +0200, Samuel Thibault wrote:
> > > That goes back to file_exec_file_name provided with a relative path, and
> > > not
> > > an
> > > absolute
Svante Signell, on sam. 09 sept. 2017 10:51:36 +0200, wrote:
> On Fri, 2017-09-08 at 00:39 +0200, Samuel Thibault wrote:
> > That goes back to file_exec_file_name provided with a relative path, and not
> > an
> > absolute path. That's where it needs fixing. I guess it could be a
> > matter of
On Fri, 2017-09-08 at 00:39 +0200, Samuel Thibault wrote:
> That goes back to file_exec_file_name provided with a relative path, and not
> an
> absolute path. That's where it needs fixing. I guess it could be a
> matter of making sysdeps/mach/hurd/execve.c call realpath(), as well as
>
Hello,
Svante Signell, on jeu. 07 sept. 2017 10:38:19 +0200, wrote:
> When working on porting gccgo to gcc-7, I found out that many test failures
> are
> due to a bug in Hurd's implementation of /proc/self/exe (and /proc//exe):
> The path returned should always be absolute, not relative.
That
Hi,
When working on porting gccgo to gcc-7, I found out that many test failures are
due to a bug in Hurd's implementation of /proc/self/exe (and /proc//exe):
The path returned should always be absolute, not relative.
Adding print statements to libbacktrace/posix.c shows the problem:
GNU/Linux:
36 matches
Mail list logo
