python gdb plugin traceback: No type named sal_uInt16.

[Riccardo Magliocchetti]

Hi Michael, Michael,

Il 29/02/2012 13:02, Michael Stahl ha scritto:
> On 29/02/12 12:48, Michael Meeks wrote:
>> Hi Riccardo,
>>
>> On Wed, 2012-02-29 at 09:23 +0100, Riccardo Magliocchetti wrote:
>>> i have this traceback every time i open a core. It does not harm but it
>>> is a bit annoying. Does anyone have a clue on how to fix that?
>>
>> 	I guess the code is in solenv/gdb/libreoffice/
 >>
>>> #1  0x00007f1648443b0b in __GI_abort () at abort.c:92
>>>           save_stage = 2
>>>           act = Traceback (most recent call last):
>>>     File "/home/rm/src/libo/solenv/gdb/libreoffice/util/printing.py",
>>> line 123, in __call__
>>>       printer = self.func_lookup[val.type]
>>>     File "/home/rm/src/libo/solenv/gdb/libreoffice/util/printing.py",
>>> line 95, in __getitem__
>>>       if test(type):
>>>     File "/home/rm/src/libo/solenv/gdb/libreoffice/svl.py", line 89, in query
>>>       ushort = gdb.lookup_type('sal_uInt16')
>>> RuntimeError: No type named sal_uInt16.
>>
>> 	I imagine that nothing was built with any debugging information, and as
>> such we don't know about the sal_uInt16 type. Perhaps catching and
>> handling the relevant RuntimeError (?) exception in the gdb python
>> helpers might help ?

Ah! i thought it was something related to that specific type, i'll take 
a look at catching the exception then.

> the gdb in Fedora 16 has these turned off by default, with an option to
> turn them on (which is very useful when debugging the pretty printers):
> 	set python print-stack
>
> perhaps you have that turned on somehow, or you have an older gdb that
> has it hard-wired enabled.

Is it?
$ gdb -v
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08

Thanks

-- 
Riccardo Magliocchetti