On Oct 22, 2009, at 12:41 PM, Kern Sibbald wrote:
>> Yes. It's a fact of life on FreeBSD.
>
> IMO building yourself is always dangerous unless you are an expert
> with the
> particular program (maybe you are with MySQL).
Really? Obviously I'm an old fart who came from "everything has to be
c
On Oct 22, 2009, at 11:10 AM, Martin Simmons wrote:
> The lines in the gdb backtrace like this:
>
> #12 0x281a1aef in pthread_create () from /usr/local/lib/mysql/
> libmysqlclient_r.so.16
>
> mean that gdb found the address 0x281a1aef to be inside the function
> pthread_create and that address is
On Thursday 22 October 2009 21:01:00 Jo Rhett wrote:
> On Oct 22, 2009, at 11:51 AM, Kern Sibbald wrote:
> >> 5.1.39
> >
> > If I am not mistaken, that is the MySQL version that was terribly
> > broken when
> > doing regression on Solaris.
>
> Can you point me at where to find which versions are kn
On Oct 22, 2009, at 11:51 AM, Kern Sibbald wrote:
>> 5.1.39
>
> If I am not mistaken, that is the MySQL version that was terribly
> broken when
> doing regression on Solaris.
Can you point me at where to find which versions are known good for
bacula?
> So you built your own MySQL?
Yes. It's
On Thursday 22 October 2009 19:40:37 Jo Rhett wrote:
> On Oct 21, 2009, at 1:09 AM, Kern Sibbald wrote:
> > What you show below is unfortunately only part of the story. To
> > understand
> > better what is going on we need a "thread apply all bt" as
> > documented in
> > the manual.
>
> (gdb) threa
> On Thu, 22 Oct 2009 07:06:40 +0200, Kern Sibbald said:
>
> On Wednesday 21 October 2009 23:58:03 Martin Simmons wrote:
> > > On Wed, 21 Oct 2009 21:53:50 +0200, Kern Sibbald said:
> > >
> > > On Wednesday 21 October 2009 20:46:00 Bob Hetzel wrote:
> > > > I added --libdir=/usr/lib64 to m
The lines in the gdb backtrace like this:
#12 0x281a1aef in pthread_create () from
/usr/local/lib/mysql/libmysqlclient_r.so.16
mean that gdb found the address 0x281a1aef to be inside the function
pthread_create and that address is within the library libmysqlclient_r.so.16.
Normally pthread_creat
Apologizes, I re-orged your response to top-posting to keep the
information in the message.
What do you mean by "the pthread implementation comes from /usr/local/
lib/mysql/libmysqlclient_r.so.16 in this backtrace" ? How would I
determine this? How can I prevent this, etc?
Note: this see
On Oct 21, 2009, at 1:09 AM, Kern Sibbald wrote:
> What you show below is unfortunately only part of the story. To
> understand
> better what is going on we need a "thread apply all bt" as
> documented in
> the manual.
(gdb) thread apply all bt
Cannot get thread info: invalid key
> Also, sinc
> I think command completion would be nice to have. Someone once sent
us a
> modification to the director that added command completion. I didn't
> accept it because it was *very* intrusive on the code and in my
opinion at
> the time it would have added a lot of complexity for little benefit.
I d
> After doing my billionth Exchange test restore I've just been thinking
> how nice it would be to be able to use the tab key to complete filenames
> during a restore. From what I can see though, the console is pretty
> 'dumb' in that it doesn't really understand bacula commands, it just
> passes
After doing my billionth Exchange test restore I've just been thinking
how nice it would be to be able to use the tab key to complete filenames
during a restore. From what I can see though, the console is pretty
'dumb' in that it doesn't really understand bacula commands, it just
passes them to the
(caution - this email is a long brain dump :)
> >
> > Any comments? It all sounds a bit hard at the moment...
>
> Yes it certainly need some thought. I am going to think about this a
bit
> more. In the mean time, can you give me a bit more information on the
> details you see for what Bacula wo
13 matches
Mail list logo
