First steps finding regression bug(s)

Rodolfo rodolforg at gmail.com
Fri Jan 18 20:46:27 PST 2013


Joren,

maybe that string is caught from here (note that's is inside Writer module)
http://opengrok.libreoffice.org/xref/core/sw/source/ui/app/error.src
Then you should try searching for ERR_AUTOPATH_ERROR or ERRCODE_CLASS_PATH.

Or here, but I don't have any idea what is UUI.
http://opengrok.libreoffice.org/xref/core/uui/source/ids.src#168
( ERRCODE_UUI_IO_NOTEXISTS )

I found these matches seraching like this
http://opengrok.libreoffice.org/search?q=%22does+not+exist.%22&project=core&defs=&refs=&path=&hist=

I've tried to use "does not exist.\"" (inserting the quote), but
opengrok ignore it.

Looking at that screenshot on bug report, I'd say the problem is the
filenames are concatenated into a single string separated by a newline
character - but I don't know anything about Mac. Or the message string
is just ugly ;)

I hope it helps.

Rodolfo

2013/1/18 Joren <joren.libreoffice at telenet.be>:
> Op 17-01-13 20:44, Michael Meeks schreef:
>
>> Hi Joren,
>>
>> On Wed, 2013-01-02 at 19:59 +0100, Joren wrote:
>>>
>>> I try now to take a little step forward and try to comprehend a bit of
>>> the source code. I would like to help core developers point at
>>> regressions (find the erroneous commit).
>>
>>         Which is really amazingly useful - thanks so much for this work. I
>> didn't see a reply to your mail - so let me have a go:
>>
>>> Following the alert, I can search for the string 'does not exists.'. I
>>> found it here:
>>
>>         A good way to try to trace this bottom-up:
>>
>>>
>>> String RID_FILEOPEN_INVALIDFOLDER
>>> {
>>> Text [ en-US ] = "$name$ does not exist.";
>>> };
>>
>>         So this is quite probably the string as you say.
>>
>> fpicker/source/office/OfficeFilePicker.hrc:#define
>> RID_FILEOPEN_INVALIDFOLDER                  (RID_FPICKER_START+23)
>> fpicker/source/office/iodlg.src:String RID_FILEOPEN_INVALIDFOLDER
>>
>>         However there are only two hits - I would expect to see some code
>> that
>> would load this string something like this:
>>
>>         String(ResId(RID_FILEOPEN_INVALIDFOLDER))
>>
>>         or somesuch; but that isn't there - so - either - we are getting
>> this
>> string by doing some arithmetic around the RID_s - sometimes strings are
>> arranged in sequence in an array so the define is only used in the .src
>> - or the string isn't used and it's the wrong one ;-)
>>
>>> Ok... Now I found this ... Can I 'conclude' that my string is at
>>> 'position'  16393 (=23 + 6370 + 10000). That's 0x4009 in hex notation.
>>> I searched for 0x4009 and 16393; but I can't find anything relevant
>>
>>         Yep - in general, the code wouldn't hard-code a specific number
>> like
>> that (it'd be terrible style at least ;-). A git grep for
>> RID_FPICKER_START shows:
>>
>> vcl/inc/vcl/fpicker.hrc:#define STR_SVT_FILEPICKER_START
>> (RID_FPICKER_START+1)
>>
>>         But looking at that - I'd rather suspect that this string is just
>> not
>> used - as such we should kill it in master (and any others we can verify
>> are not used from that .hrc).
>
> I need to check some things first before 'just delete it'?
>
>>
>>         I suspect that one of the other:
>>
>>         git grep 'does not exist."'
>>
>>         hits is the source of that string ?
>
> I found a string related to macro-handling ... but I don't think that's a
> domain I need to search?
>
>>
>>> Because the bug is a regression bug 3.5 vs 3.6, and the source code of
>>> 3.6 is frozen on "Week 23, Jun 4 - Jun 10, 2012" I compared the
>>> current version of resmgr.cxx with a version at the beginning of 2012
>>> (to be sure not overlook something)... But I couldn't find something.
>>> Otherwise with this information I still can't find the code that
>>> triggers the string.
>>
>>         Yep - the problem is unlikely to be in resmgr - that's the basic /
>> underlying translation functionality.
>>
>>         Is that helpful ? sorry for the appallingly slow reply :-)
>
> Yes :-), thanks.
> I'll abort my search for now :p. I think I'm not that advanced yet.
>
> Thanks for picking up this mail!
>
> Greets,
> Joren
>
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice


More information about the LibreOffice mailing list