First steps finding regression bug(s)

[Michael Meeks]

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 suspect that one of the other:

	git grep 'does not exist."'

	hits is the source of that string ?

> 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 :-)

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot