Re: debugger suggestions

[joce]

Hi,

Thanks for the feedback.
Actually the problems I was experiencing was due to a bug in
/BUILD/compile-pentium-debug script which was still using -O1 flag (seems
the --with-debug=full was not properly taken into account), and hence the
debugging was a nightmare.
I still need to track down the issue to understand why it happens on
vmware + kubuntu x86-64 (it works properly on debian).

Thanks,
  Jocelyn

>
> On 25 Mar 2007, at 14:08, Jocelyn Fournier wrote:
>> Just curious : what kind of OS / Debugger are you used to use
>> inside MySQL ?
>> At work I'm using solaris 10 + workshop/sunstudio (dbx) on SPARC
>> hardware which is fine, but at home I'm trying to use kubuntu +
>> KDbg (gdb), and unfortunately I'm not happy with the result...
>
> We don't use a particular environment or OS.  Internally, we're as
> heterogeneous as the rest of our users; in fact, I think we'd
> consider it a dire emergency if we were a monoculture and not a cross-
> section of the community.
>
> I use mostly Ubuntu and plain old GDB or I'll pepper the source code
> with printfs (DBUG_PRINT, to be exact).  When the pointers are so
> complex that I'd need paper to graph them, I usually resort to DDD.
>
> - chad
>
>
>> Chad MILLER a écrit :
>>> [add CC jimw]
>>> On 20 Mar 2007, at 11:32, joce@stripped wrote:
>>>> I assume implementing %f is linked to WL#2934 ?
>>> Hi Jocelyn.
>>> No, I don't think there's a dependent relationship.  It would be
>>> nice to have WL#2934 implemented, but clever use of mundane sprintf
>>> () could solve this specific case well enough until it is.  We'll
>>> want to put a note in that worklog to refactor my_snprintf()
>>> later.  We're obviously not using "%f" in many places, and here
>>> it's not something that would trigger the platform-specific
>>> variances in values.
>>>> What's the status of the functions in decimal.c ?
>>>> (especially double2decimal and decimal2string)
>>> Heh, I didn't know until I just now looked.   double2decimal()
>>> uses sprintf(s, "%.16G", from) to get to a string, and then
>>> converts that string to the internal decimal type.  That's
>>> somewhere we'll eventually refactor when WL#2934 is implemented.
>>> So, if you think you'd like to use that, I imagine it's okay.
>>> - chad
>>>>>
>>>>>> --- sql_parse.cc.old    2007-03-03 17:53:15.000000000 +0100
>>>>>> +++ sql_parse.cc    2007-03-03 17:53:31.000000000 +0100
>>>>>> @@ -2119,7 +2119,7 @@
>>>>>>             &LOCK_status);
>>>>>>      calc_sum_of_all_status(&current_global_status_var);
>>>>>>      uptime= (ulong) (thd->start_time - start_time);
>>>>>> -    length= my_snprintf((char*) buff, buff_len - 1,
>>>>>> +    length= snprintf((char*) buff, buff_len - 1,
>>>>>>                          "Uptime: %lu  Threads: %d  Questions: %
>>>>>> lu  "
>>>>>>                          "Slow queries: %lu  Opens: %lu  Flush
>>>>>> tables: %lu  "
>>>>>>                          "Open tables: %u  Queries per second
> avg:
>>>>>> %.3f",
>>>>>
>>>>>
>>>>> In addition to Sergei's comment that we should never use snprintf()
>>>>> outside the check for HAVE_SNPRINTF, the return value of snprintf()
>>>>> varies across implementations, so we should never even trust
>>>>> "length"
>>>>> in this case.  Thus, another reason we can't accept this approach.
>>>>> You're right, that adding floating-point decoding to my_snprintf
>>>>> () is
>>>>> the right approach.
>>>>>
>>>>> Jocelyn, are you comfortable implementing "%f"?
>>>>>
>>>>> - chad
>>> --
>>> Chad Miller, Software Developer
>>> chad@stripped
>>> MySQL Inc., www.mysql.com
>>> Orlando, Florida, USA                                13-20z,
>>> UTC-0400
>>> Office: [phone]                         sip:
>>> 6740@stripped
>>
>> --
>> MySQL Internals Mailing List
>> For list archives: http://lists.mysql.com/internals
>> To unsubscribe:    http://lists.mysql.com/internals?
>> unsub=cmiller@stripped
>>
>
> --
> Chad Miller, Software Developer                         chad@stripped
> MySQL Inc., www.mysql.com
> Orlando, Florida, USA                                13-20z,  UTC-0400
> Office: [phone]                         sip:6740@stripped
>
>
>