On Wed, May 21, 2014 at 12:47 AM, Svante Signell
wrote:
> On Wed, 2014-05-21 at 01:27 +0200, Samuel Thibault wrote:
>> Svante Signell, le Fri 16 May 2014 10:03:05 +0200, a écrit :
>> > is used in gcc-4.9-4.9.0/src/libgo/go/net/fd_unix.go:
>> > func dupCloseOnExec(fd int) (newfd int, err error) {
>
Svante Signell, le Wed 21 May 2014 09:47:08 +0200, a écrit :
> > > +# Special treatment of EWOULDBLOCK for GNU/Hurd
> > > +# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
> > > +if egrep 'define EWOULDBLOCK EAGAIN' gen-sysinfo.go > /dev/null 2>&1;
> > > then
> > > + egrep '^const EWOULDBL
Svante Signell, le Fri 16 May 2014 10:03:05 +0200, a écrit :
> is used in gcc-4.9-4.9.0/src/libgo/go/net/fd_unix.go:
> func dupCloseOnExec(fd int) (newfd int, err error) {
> if atomic.LoadInt32(&tryDupCloexec) == 1 && syscall.F_DUPFD_CLOEXEC!=0 {
> r0, _, e1 := syscall.Syscall(syscall.SYS_FCNTL, ui
On Fri, 2014-05-16 at 06:20 -0700, Ian Lance Taylor wrote:
> On Fri, May 16, 2014 at 1:03 AM, Svante Signell
> wrote:
> >
> > For that part of the patch without it the build on GNU/Hurd fails. On
> > the other hand SYS_FCNTL is not defined for e.g. GNU/Linux either. This
> > is used in gcc-4.9-4.9
On Fri, May 16, 2014 at 1:03 AM, Svante Signell
wrote:
>
> For that part of the patch without it the build on GNU/Hurd fails. On
> the other hand SYS_FCNTL is not defined for e.g. GNU/Linux either. This
> is used in gcc-4.9-4.9.0/src/libgo/go/net/fd_unix.go:
> func dupCloseOnExec(fd int) (newfd in
On Wed, 2014-05-07 at 10:18 +0200, Svante Signell wrote:
> On Tue, 2014-05-06 at 15:26 +0200, Samuel Thibault wrote:
Attached is an updated patch8.diff. Arch specific code to
src/libgo/mksysinfo.sh has been added, now other systems are not
affected by the patch except the SYS_FCNTL part.
For that
On Tue, 2014-05-06 at 15:26 +0200, Samuel Thibault wrote:
> Svante Signell, le Tue 06 May 2014 15:25:38 +0200, a écrit :
> > On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote:
> > > Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> > > > On Tue, 2014-05-06 at 14:51 +0200, Samuel
Svante Signell, le Tue 06 May 2014 15:25:38 +0200, a écrit :
> On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote:
> > Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> > > On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> > > > Just to explicitly ask for it:
> > > >
>
On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote:
> Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> > On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> > > Just to explicitly ask for it:
> > >
> > > Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > >
Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
> On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> > Just to explicitly ask for it:
> >
> > Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > > For some (yet) unknown reason all libgo tests fails with a segfault
On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
> Just to explicitly ask for it:
>
> Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> > For some (yet) unknown reason all libgo tests fails with a segfault when
> > run in the build tree: make, sh or something else, the test c
On Tue, May 6, 2014 at 4:06 AM, Svante Signell wrote:
> On Fri, 2014-05-02 at 12:52 +0200, Samuel Thibault wrote:
>> Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
>> > On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
>> > > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200
Just to explicitly ask for it:
Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
> For some (yet) unknown reason all libgo tests fails with a segfault when
> run in the build tree: make, sh or something else, the test commands are
> rather hard to track.
Doesn't that dump a core? Do y
On Fri, 2014-05-02 at 12:52 +0200, Samuel Thibault wrote:
> Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
> > On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> > > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > > > So we just need to fix guardsize in our
Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
> On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > > So we just need to fix guardsize in our libpthread.
> >
> > (And I'll have a look at it).
>
> Maybe this
On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> > So we just need to fix guardsize in our libpthread.
>
> (And I'll have a look at it).
Maybe this can fix the around 40 segfaults (of 50 failures) when split
stack is disab
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> So we just need to fix guardsize in our libpthread.
It was not so difficult actually.
Svante, could you try this libpthread:
http://people.debian.org/~sthibault/tmp/libpthread.so.0.3
Thanks,
Samuel
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
> So we just need to fix guardsize in our libpthread.
(And I'll have a look at it).
Samuel
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
> task130(pid1182)->vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space
> available)
> task130(pid1182)->vm_allocate (33571160 8364 0) = 0 33570816
While inspecting this, I realized this is from __pthread_stack_alloc,
the only call
Justus Winter, le Sat 26 Apr 2014 08:53:08 +0200, a écrit :
> task130(pid1182)->vm_map (0 49880 0 1133<--160(pid1182) 0 1 5 7 1) = 0
> 2453504
>
> We map that somewhere.
>
> task130(pid1182)->mach_port_deallocate (pn{ 25}) = 0
>
> Deallocate the port. Again, for some strange reason 133 ==
Svante Signell, le Fri 02 May 2014 10:03:23 +0200, a écrit :
> On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
> > Hello,
> >
> > Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> > > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > > most of them w
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
> Thread 4 (Thread 1205.4):
> #0 0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
> err =
> err =
> user_option = 3
> user_timeout = 48
> m = 0x532370
> msgh_bits = 0
>
On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
> Hello,
>
> Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> > - Without split stack enabled around 70 libgo tests pass and 50 fails,
> > most of them with a segfault.
> > - Enabling split stack and using the libc Samuel buil
Hello,
Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
> - Without split stack enabled around 70 libgo tests pass and 50 fails,
> most of them with a segfault.
> - Enabling split stack and using the libc Samuel built all 122 libgo
> tests fail with a segfault.
Please provide segfault
Quoting Svante Signell (2014-04-26 13:59:57)
> > For reference, here are my notes about one of these crashes (Svante,
> > is this still current?):
>
> Yes it is, thanks for your help so far. Is the rpctrace bug you
> mentioned that the wrong ports are reported?
>
> > ~~~ snip ~~~
> > [...]
> > ta
±On Sat, 2014-04-26 at 08:53 +0200, Justus Winter wrote:
> Quoting Svante Signell (2014-04-24 10:39:10)
> > On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
> > > Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> > > > Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écr
Quoting Svante Signell (2014-04-24 10:39:10)
> On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
> > Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> > > Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > > > Well, the first step is to verify that TARGET_THREAD
On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> > Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > > Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> > > and similar configury is co
Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
> Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> > Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> > and similar configury is correct for the Hurd,
>
> I have added the corresponding field, so
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> and similar configury is correct for the Hurd,
I have added the corresponding field, so we can just use the same offset
as on Linux.
Samuel
Samuel Thibault, le Sat 12 Apr 2014 01:04:49 +0200, a écrit :
> Samuel Thibault, le Fri 11 Apr 2014 23:51:44 +0200, a écrit :
> > So, do we really want to let munmap poke a hole at address 0 and thus
> > let further vm_map() return address 0?
>
> i.e. we could apply this:
I have applied it.
Samu
On Fri, Apr 11, 2014 at 11:51:44PM +0200, Samuel Thibault wrote:
> It's indeed:
>
> /* This function is called at program startup time to make sure that
>mmap, munmap, and getpagesize are resolved if linking dynamically.
>We want to resolve them while we have enough stack for them, rather
Samuel Thibault, le Fri 11 Apr 2014 23:51:44 +0200, a écrit :
> So, do we really want to let munmap poke a hole at address 0 and thus
> let further vm_map() return address 0?
i.e. we could apply this:
diff --git a/sysdeps/mach/munmap.c b/sysdeps/mach/munmap.c
index 57d99f9..a46e3f1 100644
--- a/s
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
> Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
> and similar configury is correct for the Hurd,
It's not. I've checked what TARGET_THREAD_SPLIT_STACK_OFFSET is, it's
an offset inside the tcbhead_t structure,
Hi!
On Wed, 9 Apr 2014 09:05:46 +0200, Svante Signell
wrote:
> On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
> > Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> > > On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor
> > > wrote:
> > > > Go can work without split s
On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
> Hello,
>
> Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> > On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor
> > wrote:
> > > Go can work without split stack. In that case libgo will use much
> > > larger stacks fo
Hello,
Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
> On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor wrote:
> > Go can work without split stack. In that case libgo will use much
> > larger stacks for goroutines, to reduce the chance of running out of
> > stack space (see S
Hi!
On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor wrote:
> Go can work without split stack. In that case libgo will use much
> larger stacks for goroutines, to reduce the chance of running out of
> stack space (see StackMin in libgo/runtime/proc.c). So the number of
> simultaneous gorout
38 matches
Mail list logo
