Applied, thanks!
Yuqian Yang, le mer. 29 janv. 2025 23:14:31 +0800, a ecrit:
> Many people are familiar with VirtualBox, or using OS other than
> GNU/Linux. VirtualBox gives them more opportunity to play with Hurd.
> ---
> hurd/running/virtualbox.mdwn | 19 +--
> index.mdwn
Many people are familiar with VirtualBox, or using OS other than
GNU/Linux. VirtualBox gives them more opportunity to play with Hurd.
---
hurd/running/virtualbox.mdwn | 19 +--
index.mdwn | 2 ++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/hur
On Sun, Oct 13, 2002 at 06:06:14PM +0200, Marcus Brinkmann wrote:
> (to Jeff) You are right, glibc 2.3 is quite broken for us.
>
> I don't even come to a login prompt. postinst segfaults, runsystem
> segfaults, and the system soon crashes.
ok, I found out a bit more. I could reproduce this in
The trouble is that the compiler is for some reason copying the argument
into a local stack slot and passing the address of that instead for &argc.
That faults because it happens to be the edge of the stack. In the case
where there is an argc word on the stack (i.e. when run by the kernel), it
pr
On Tue, Jan 08, 2002 at 01:02:26AM +0100, Marcus Brinkmann wrote:
> BTW, the corresponding glibc-2.2.4/gcc2.95 code for the above code (function
> in function) is
>
> _hurd_stack_setup:
> pushl %ebp
> movl %esp,%ebp
> subl $24,%esp
> leal 8(%ebp),%eax
> mov
On Mon, Jan 07, 2002 at 10:51:40PM +0100, Marcus Brinkmann wrote:
> 0x8048494 <_hurd_stack_setup>: push %ebp
> 0x8048495 <_hurd_stack_setup+1>:mov%esp,%ebp
> 0x8048497 <_hurd_stack_setup+3>:push %ebx
> 0x8048498 <_hurd_stack_setup+4>:sub$0x24,%esp
> 0x804849b <
Hi,
libio enabled glibc, gcc 3.0, static binaries die in _hurd_stack_setup at
start up time. I think the code is gcc generated, probably for the vararg.
Here is the relevant debug info. I am not too familiar with that code gcc
generates for what type of function invocation etc. Maybe the vara
Here is more information on driving traffic to your site.
Pointcom.com is a pay-per-click search engine that operates in a similar
way to Goto.com. We have established ourselves as a safe and reliable
source of quality traffic over the past 7 years and look forward to
strengthening our posit
D'oh! I noticed that and fixed it in my tree but didn't see how it could
produce the results you saw. But I think I was believing the bogus gdb
output you showed, and nothing explained those bit patterns if gdb was
showing you the right locations. I've checked in my fix now, which should
be abo
Hi,
The type variable was declared const, so here is a new version.
(I find this resetting of type a bit strange, but it is what is used in the
select case, so I copy it).
2001-10-28 Marcus Brinkmann <[EMAIL PROTECTED]>
* hurd/hurdselect.c (_hurd_select): Set type to zero if
S
On Sat, Oct 27, 2001 at 09:59:15PM -0400, Roland McGrath wrote:
> At a quick glance, the code for both (hurdselect.c) looks the same to me,
> but I don't have time right now to examine it too thoroughly. If the
> problem with poll does not happen with select, then hurdselect.c is almost
> certain
On Sat, Oct 27, 2001 at 10:12:12PM -0400, Roland McGrath wrote:
> > Similar on line 93 already. d[1] is not initalized correctly.
>
> Well, there's nothing but simple C code before that.
> You can step through from the beginning of the function and see it all.
>
> Be careful not to let gdb confu
> Similar on line 93 already. d[1] is not initalized correctly.
Well, there's nothing but simple C code before that.
You can step through from the beginning of the function and see it all.
Be careful not to let gdb confuse you. Sometimes it reports bogus types
for variable-sized arrays.
On Sat, Oct 27, 2001 at 09:59:15PM -0400, Roland McGrath wrote:
> I see. It might be telling to recode it using select and see if it behaves
> the same.
D'oh! We had it using select before, and rewrote syslogd to use poll().
I might be able to just use an old version of the code.
> Of course,
On Sun, Oct 28, 2001 at 02:58:30AM +0100, Marcus Brinkmann wrote:
> > (gdb) print d[1].type
> > $23 = -1962934272
> >
> > If gdb doesn't play tricks on me, this is certainly bogus.
> > Note that the first descriptor (0) is the unix socket, while
> > the second is the inet socket.
>
> Similar on
I see. It might be telling to recode it using select and see if it behaves
the same. Of course, it would be best if you could reproduce the situation
with a simple test program (e.g. have a process that writes on a unix
socket every few seconds, nothing writing on the inet socket, and a simple
p
On Sun, Oct 28, 2001 at 02:50:46AM +0100, Marcus Brinkmann wrote:
> On Sun, Oct 28, 2001 at 02:37:28AM +0100, Marcus Brinkmann wrote:
> > So glibc returns the wrong values in revents for poll. I am now going to
> > look into glibc select code.
> >
>
> Actually, in hurdselect.c, line 394ff:
>
>
On Sun, Oct 28, 2001 at 02:37:28AM +0100, Marcus Brinkmann wrote:
> So glibc returns the wrong values in revents for poll. I am now going to
> look into glibc select code.
>
Actually, in hurdselect.c, line 394ff:
(gdb) print d[0].type
$22 = 9
(gdb) print d[1].type
$23 = -1962934272
If gdb doe
On Sat, Oct 27, 2001 at 09:40:59PM -0400, Roland McGrath wrote:
> That syslogd backtrace just shows that it is waiting in recvfrom,
> as it normally should be. The interesting state is in pflocal.
Actually not, see my follow up information. syslogd listens on
both unix and inet ports, and the r
That syslogd backtrace just shows that it is waiting in recvfrom,
as it normally should be. The interesting state is in pflocal.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Sun, Oct 28, 2001 at 02:06:48AM +0100, Marcus Brinkmann wrote:
> So at least two bugs involved here? It seems so. Below you can see
> the gdb output of syslogd at the time of sudo hanging. I should be able
> to narrow it further than that by debugging syslogd in more detail.
It was instruct
Hi,
I am happy to be able to present some more info on the problems involving
sudo/pflocal/syslogd.
There seem to be a couple of issues. First, it seems that sudo and
pflocal/libpipe seem to work fine in the normal case. What happens
is that sudo sends a diagnostic line to syslogd. syslogd
> > You might turn on some of the libc debugging stuff when starting pfinet.
>
> Can you be more specific?
I meant the malloc debugging stuff. There are some environment variables.
Look in the libc sources.
> Attached. Hope it helps.
That backtrace definitely looks bogus.
> esp
On Wed, Jan 17, 2001 at 12:06:51AM -0500, Roland McGrath wrote:
> > Seriously, I think this is some trouble with the condition_wait/select
> > stuff. Pending bytes don't seem to be delivered or wake a waiting select.
>
> Well, we know that much. We need to get more specific. That's why I
> want
> I didn't follow that track, because it was coming from libwrap (tcp
> wrapper), and I was not set up to debug there. Instead, I let inetd start
> telnetd directly, and attached gdb to pfinet before doing so.
tcpd just execs telnetd after doing the access check. So when you have an
open connect
On Tue, Jan 16, 2001 at 05:59:47AM -0500, Roland McGrath wrote:
> The IP options are bogus--they are not really there. Figure out how it is
> that telnetd thinks it is getting IP options. Whatever is returning an
> indication of IP options must be a bug (in libc or pfinet).
I didn't follow that
The IP options are bogus--they are not really there. Figure out how it is
that telnetd thinks it is getting IP options. Whatever is returning an
indication of IP options must be a bug (in libc or pfinet).
F_SETOWN might in fact not work, I guess it should. That translates to
io_mod_owner. Is
Hi,
I'm moving this to bug-hurd.
I have compiled pfinet from 2000-08-29, it shows the same problems, so this
is not related to any of my recent changes in pfinet. I set up the
translator as follows:
settrans /servers/socket/2 /hurd/pfinet
So there is really only the loopback interface. I don't
28 matches
Mail list logo
