Closed Bug 613846 Opened 10 years ago Closed 10 years ago

NSLDAP32V60.dll symbols don't seem to have paths to files

Categories

(MailNews Core :: Build Config, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.3a2

People

(Reporter: timeless, Assigned: standard8)

References

Details

Attachments

(1 file)

bp-9e40f408-f64a-4af4-b1f1-7f7832101027 (Todd)
EXCEPTION_ACCESS_VIOLATION_READ
0xc1
0	NSLDAP32V60.dll	ldap_abandon_ext	abandon.c:5.4:103
1	thunderbird.exe	nsLDAPOperation::SimpleBind	directory/xpcom/base/src/nsLDAPOperation.cpp:353

I'm hoping this is some strange build config flag. can this be fixed?
I'm vaguely remembering that there's some code around which determines paths based on where repositories/files are for symbols.

I'm not totally sure, but this might resolve itself (or be helped) once bug 506601 is fixed and we have LDAP in hg, since that shouldn't be too far off now, let's add a dependency and wait and see what happens.
Depends on: 506601
The symbol file has encoded cvs info:
FILE 4362 cvs:cvs-mirror.mozilla.org/cvsroot:inspectore:/buildbot/win32_build/build/directory/c-sdk/ldap/libraries/libldap/abandon.c:5.4


but it's using cvs-mirror.mo, and I think Socorro only knows about cvs.mo. We should be able to simply add cvs-mirror to vcsMappings as a copy of cvs.mo (ala bug 572525). I think links still won't work, since the path looks kind of goofy: "inspectore:/buildbot/win32_build/build/directory/c-sdk/ldap/libraries/libldap/abandon.c". Not sure what's happening there.
Mark: if you start pulling LDAP from a hg repo, and you fix:
http://mxr.mozilla.org/comm-central/source/Makefile.in#115

to add its directory to the srcdirs list, and you get Socorro to add the LDAP repo to vcsMappings, then this will probably work as intended.
Assignee: nobody → bugzilla
This is more comm-central build config, so moving to a more appropriate component.
Component: LDAP C SDK → Build Config
Product: Directory → MailNews Core
QA Contact: csdk → build-config
Version: other → Trunk
I've built this on try server with no adverse affects. I'm not sure if there's a way to easily test all of this before landing it, but I think we can land it, check the effects and then tweak other things if necessary.
Attachment #499501 - Flags: review?(bugspam.Callek)
Attachment #499501 - Flags: review?(bugspam.Callek) → review?(gozer)
Comment on attachment 499501 [details] [diff] [review]
Fix generation of symbols

whops, missed the initial request.
Attachment #499501 - Flags: review?(gozer) → review+
(In reply to comment #3)
> and you get Socorro to add the LDAP
> repo to vcsMappings, then this will probably work as intended.

Just don't forget to have that fix.
Checked in: http://hg.mozilla.org/comm-central/rev/06ef96c48def

Leaving this bug open whilst we get Socorro mappings updated (I'll file the bug later).
Flags: in-testsuite-
Target Milestone: --- → Thunderbird 3.3a2
According to some crashes I submitted yesterday (from the latest nightly), this seems to have broken all file location links on crash-stats, e.g.

http://crash-stats.mozilla.com/report/index/bp-298d48f2-24d8-495c-8302-6bd022110105

http://crash-stats.mozilla.com/report/index/bp-ac39c83e-231c-4584-94b2-0b10a2110105

At the moment I have two theories:

1) the code is wrong.
2) not having the VCS mapping for LDAP is blowing up Socorro.

I'm going to aim for 2 and see what happens.
Depends on: 623471
I just noticed that the reference I added to the ldap-sdk could be perceived as wrong, depending on how intelligent the code is. I noticed this in checking the symbols file for the ldap dlls which had file information pointing to comm-central.

I've therefore submitted a change which changes $(topsrcdir)/ldap/sdks/c-sdk to $(topsrcdir)/ldap/sdks

Maybe that will help the symbols issue as well:

http://hg.mozilla.org/comm-central/rev/590ed57dd254
(In reply to comment #9)
> According to some crashes I submitted yesterday (from the latest nightly), this
> seems to have broken all file location links on crash-stats, e.g.
> 
> http://crash-stats.mozilla.com/report/index/bp-298d48f2-24d8-495c-8302-6bd022110105
> 
> http://crash-stats.mozilla.com/report/index/bp-ac39c83e-231c-4584-94b2-0b10a2110105
> 
> At the moment I have two theories:
> 
> 1) the code is wrong.
> 2) not having the VCS mapping for LDAP is blowing up Socorro.

I do not believe #2, having seen crash reports in the past with some missing mappings, they don't look like your crash reports.

If you look at the raw dump output of one of your reports, you'll see things like:
0|0|XUL|nsLDAPAutoCompleteSession::FinishAutoCompleteLookup|../../../../../mailnews/addrbook/src/nsLDAPAutoCompleteSession.cpp|970|0x0

The source filename is missing all the VCS info that symbolstore.py is supposed to munge into it.
A bit more information.

The issues I'm seeing seems to be mac only, not on Firefox, definitely on Thunderbird. I've also just seen a crash report from before this landed which is also broken. Therefore I don't think that the issues are the same.

The ldap in vcs mapping bug is filed, so I'll close this one now (weirdly the ldap part seems to be working from the symbol files I've seen).
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.