Closed Bug 1156300 Opened 7 years ago Closed 6 years ago

FixFilenameCase doesn't fix up directory names


(Toolkit :: Crash Reporting, defect)

Windows 8.1
Not set



Tracking Status
firefox48 --- fixed


(Reporter: away, Assigned: ted)




(1 file)

The file links on this crash report point to 'libglesv2' when it should be 'libGLESv2':
I think nowadays we could use GetFinalPathNameByHandle:
Duplicate of this bug: 1241998
This bug is lacking context, but:

When we dump symbols from PDB files we attempt to normalize the case of source filenames to match what's on the filesystem. Visual C++ tries its hardest to make life difficult for us by using arbitrary case. Unfortunately until recently there weren't actually any APIs for getting the canonical filename case, so this is a PITA.
Duplicate of this bug: 1245750
Duplicate of this bug: 1252514
Who do I need to bribe to get this fixed?
Flags: needinfo?(ted)
I will fix this when I'm back home with my Windows machine on Friday.
Assignee: nobody → ted
Flags: needinfo?(ted)
I did `mach buildsymbols` with this patch locally, and grepping xul.sym file it produced shows lines like:
FILE 40997 hg:

So this seems to do the trick. (Also I wrote tests for it, and they pass, so that's nice.) Try push just to sanity check I didn't break anything in weird ways.
Apparently Python 3 has os._getfinalpathname on Windows that calls this under the hood:

That would have made this patch easier!
Attachment #8739945 - Flags: review?(gps) → review+
Comment on attachment 8739945 [details]
MozReview Request: bug 1156300 - FixFilenameCase doesn't fix up directory names. r?gps

::: toolkit/crashreporter/tools/
(Diff revision 1)
> +            size = ctypes.windll.kernel32.GetFinalPathNameByHandleW(handle,
> +                                                                    None,
> +                                                                    0,
> +                                                                    0)
> +            buf = ctypes.create_unicode_buffer(size)
> +            if ctypes.windll.kernel32.GetFinalPathNameByHandleW(handle,
> +                                                                buf,
> +                                                                size,
> +                                                                0) > 0:

I would have allocated a fixed length buffer and called GetFinalPathNameByHandleW once then sliced. But meh.

> I would have allocated a fixed length buffer and called GetFinalPathNameByHandleW once then sliced. But meh.

Unfortunately this is the only sensible way to handle arbitrary path sizes. I, too, hate the Win32 API for this, but it's the best you can do with C.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #9)

I downloaded the symbols from this build to further sanity check and they look sensible:
FILE 174525
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Duplicate of this bug: 475726
You need to log in before you can comment on or make changes to this bug.