On Mon, Feb 04, 2002 at 02:33:40PM -0700, Sasha Pachev wrote:
> On Monday 04 February 2002 11:59 am, Jeremy Zawodny wrote:
> > >?This does look like a libc bug. How did you build either one of the
> binaries?
> >
> > They're your binaries. ?I don't buld my own binaries on Linux to save
> > the h
On Monday 04 February 2002 11:59 am, Jeremy Zawodny wrote:
> >?This does look like a libc bug. How did you build either one of the
binaries?
>
> They're your binaries. ?I don't buld my own binaries on Linux to save
> the hassle of using libraries that are different from what you folks
> use. :-)
On Mon, Feb 04, 2002 at 10:08:37AM -0700, Sasha Pachev wrote:
> On Monday 04 February 2002 02:30 am, Jeremy Zawodny wrote:
> > 0x807bb5f handle_segfault__Fi + 383
> > 0x82a94aa pthread_sighandler + 154
> > 0x7cb80076 __evoke_link_warning_llseek + 1954074198
> > 0x7cb7fe19 __evoke_link_warning_llse
On Mon, Feb 04, 2002 at 07:15:33PM +0200, Sinisa Milivojevic wrote:
>
> Yes, this is troubling ...
>
> It could be hardware, though ...
>
> Can you find anything in MySQL log and especially in /var/log/dmesg
> or /var/log/messages.
Nope.
> Sometimes, not often, Linux kernel is capable of not
Jeremy Zawodny writes:
> On Mon, Feb 04, 2002 at 02:27:01PM +0200, Sinisa Milivojevic wrote:
>
> That was your binary on Linux.
>
> Strangely, I just started up that exact same copy of 3.23.47-max and
> it worked fine after a machine reboot.
>
> That's most unusual (and troubling).
>
> Thanks,
On Monday 04 February 2002 02:30 am, Jeremy Zawodny wrote:
> 0x807bb5f handle_segfault__Fi + 383
> 0x82a94aa pthread_sighandler + 154
> 0x7cb80076 __evoke_link_warning_llseek + 1954074198
> 0x7cb7fe19 __evoke_link_warning_llseek + 1954073593
> 0x7cb713e6 __evoke_link_warning_llseek + 1954013638
>
On Mon, Feb 04, 2002 at 02:27:01PM +0200, Sinisa Milivojevic wrote:
>
> Jeremy,
>
> It could also be a bug in glibc.
>
> As you are using Linux, can you try out binary ??
That was your binary on Linux.
Strangely, I just started up that exact same copy of 3.23.47-max and
it worked fine after
TECTED]>
Sent: Monday, February 04, 2002 1:49 PM
Subject: Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
> jocelyn fournier writes:
> > Hi,
> >
> > About glibc, I saw the 2.2.5 release included the spinlock.c patch, part
of
> > the intern
jocelyn fournier writes:
> Hi,
>
> About glibc, I saw the 2.2.5 release included the spinlock.c patch, part of
> the internals.h (except the following part :
> -#define STACK_SIZE (2 * 1024 * 1024)
> +#define STACK_SIZE (128 * 1024)
> )
> The local_lim.h is also partially patched :
>
> The fol
ssage -
From: "Sinisa Milivojevic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, February 04, 2002 1:27 PM
Subject: Re: mysqld crash & stack trace from 3.23.47-max (with InnoDB)
> Jeremy Zawodny writes:
> > I just atte
Hi!
InnoDB seems to have created the database and started ok. This does not look
like an InnoDB bug.
I think gethostbyaddr asks from a connection the hostname, and subsequent
code checks that the host has access rights to mysqld.
For some reason gethostbyaddr_r crashes.
Hmm.. if you could run
I just attempted to upgrade a 3.23.41-max server on Linux 2.4.12 to
3.23.47-max. Before starting up 3.23.47-max, I added several Innodb
options to the my.cnf file:
---snip---
innodb_data_file_path = ibdata1:2000M;ibdata2:2000M;ibdata3:2000M;ibdata4:2000M
innodb_data_home_dir = /home/mysql/yahoo/
12 matches
Mail list logo
