when I enter in a email reciepient usually like so brian and then wait for the lookup in my addressbook, if it doesn't immediately find a response, when I hit backspace, i get a complete freeze. task manager from there is the only way out. kills all mozilla windows. i'm using LDAP lookup ...
ok. i can turn the crash on and off by changing the setting in my LDAP lookup. if i leave the base DN blank --> crash enter in the base DN --> lookup works remove it --> crashed again I'm using an OpenLDAP server on linux. i thought i had it configured to use a default DN for searches -- seems to work fine with other programs like gq.
Summary: mail and mozilla crash when entering email recipient → mail and mozilla crash when entering email recipient (ldap)
Over to LDAP for investigation.
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → LDAP Mail/News Integration
Ever confirmed: true
Assignee: sspitzer → srilatha
QA Contact: esther → yulian
It would be helpful with a stacktrace, if you can get that and reproducable steps on a fresh profile.
I don't see this problem testing a build from the Linux tip against an iPlanet directory server. I bet Leif has an OpenLDAP server setup that we could try to bang on. Curtis: what build are you using?
build?: its my win2k machine -- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628 -- is that what you're looking for ? the LDAP server is on a Debian GNU/Linux machine (2.2r3) ldap://alpha.liminis.net (my first attempt at running ldap -- it seems to work pretty well)
I'm trying to replicate this at work and dan't do it. At home I was able to do it repeatedly -- I'll try again at home and see if I can isolate the problem. The only diference I can think of at the moment is here at work I installed 9.2 and have NS4.7 (work standard) and explorer. At home I installed 9.2 after unistalling 9.1. Also have NS 6.01 and explorer installed.
Seems like your build should be new enough. Hmmmm...
Severity: normal → critical
Summary: mail and mozilla crash when entering email recipient (ldap) → mail and mozilla hang when entering email recipient (ldap)
Well, I got home and reproduced the bug again. I then made a change in my LDAP config file and restarted the service -- fixed. Uncomment the line and restart -- crash. Not really a bug with Mozilla or LDAP, maybe jsut a bad combination of misconfiguration on my part (LDAP) and Mozilla not liking the response. The pertinent line in my slapd.conf file was : # Where clients are refered to if no # match is found locally # referral ldap://ldap.four11.com originally the referral line was uncommented -- but i don't think that is a valid server anymore. I'm not sure what would happen if a put in a valid referral, since I don't know of the appropriate server to refer to ... sorry. If you guys need more information I'd be happy to send alond the config file or try some other referral statements to see if the bug will happen in other cicumstances. Cheers, Curtis Nelson
Marking P2, 0.9.4.
Assignee: srilatha → leif
Priority: -- → P2
Target Milestone: --- → mozilla0.9.4
The same happens to me when I start mozilla when I'm at home and have a none reachable ldap server (from our intranet) configured. Mozilla quits responding completely and even several Linux programs (gterm) quit responding to keyboard input. Only when I configure a dummy ip-addres on my ethernetcard with the address of our ldap server (the name/address is also in my /etc/hosts) I get a fairly quick timeout.
I'm pretty sure I've verified that this is inded a bug. We do not seem to follow referrals properly, at least not "smart referrals". :-( I'll investigate further as I find out more. Internal people, if you'd like to test this yourself, I've set up two referrals. The server is "data.netscape.com", the first referral is on the "base" dc=testes,dc=com which will return a referral back to our internal LDAP server. The second referral is on the same server, with the base dc=testes2,dc=com this one however has a referral back to "data.netscape.com". I've tested Mozilla 6.1 against both bases (testing both kind of referrals), and it hangs in both cases. What's worse, I see no attempt to connec to the referral URL, after it gets the referral message, it just hangs and do not do anything else. -- Leif
changed the summary to be more descriptive. this will be a big problem for enterprise deployments.
Summary: mail and mozilla hang when entering email recipient (ldap) → mail and mozilla hang when following referrals
Adding hang keyword. Request PDT+.
Leif, seems like this could be release noted for enterprise since they'll have control of the LDAP configurations and can avoid creating the bad situation. I also don't see a patch yet, so it's better to not take a fix if at this point if a release note will suffice. If you agree, please move this out of 094 milestone.
nsbranch+, stop ship for enterprise customers.
As a stop gap meassure, I've made a patch that disabled referrals in the C-SDK. This prevents the UI/browser from hanging, but it means referrals will not be followed at all. Requesting r= from dmose, and sr= from bienvenu to check in on trunk asap. I'll continue to work on finding out where in the C-SDK we're hanging. -- Leif
Created attachment 49976 [details] [diff] [review] Disable automatic following of referrals in C-SDK
Comment on attachment 49992 [details] [diff] [review] Ack, first patch took out an extra line :( r=dmose
Attachment #49992 - Flags: review+
sr=bienvenu on the second patch.
Oh yes, I forgot: credits to selmer for pointing me in this direction. I know, it's weird, but sometimes managers/directors have good ideas. ;-) -- Leif
I finally figured out where referrals were going wrong, and with a lot of help From Mark Smith, we have a real solution. The latest patch fixes the hanging problem, *and* it makes referrals work properly. Requesting r= from dmose, and sr= from bienvenu on the latest patch. Thanks, -- leif
Comment on attachment 50170 [details] [diff] [review] Patch for referrals, after dmose review firstname.lastname@example.org
Attachment #50170 - Flags: review+
Comment on attachment 50170 [details] [diff] [review] Patch for referrals, after dmose review And you need to unapply the previous patch, right?
Attachment #50170 - Flags: superreview+
Right, the first patch is obsolete, it was never checked in actually. Thanks! -- leif
Comment on attachment 49992 [details] [diff] [review] Ack, first patch took out an extra line :( This patch no longer needed, since we have a real solution that solves this correctly.
Attachment #49992 - Attachment is obsolete: true
Adding correctness Status Whiteboard, correct/expected behavior does not occur.
Whiteboard: PDT → PDT,[correctness]
Hmmm, what does "correctness" mean? I haven't checked this patch in on the trunk yet. -- Leif
Great catch, Leif! Lets bake this on the trunk for a couple of days. Would you please get this tested on all platforms once this is on the trunk? Thanks a lot!
Comment on attachment 50170 [details] [diff] [review] Patch for referrals, after dmose review Checked in on trunk
Verified with 20010924 trunk builds on Windows NT, Wins2k, Linux and MacOS 9.2.
Verified with 20010924 trunk builds on Windows XP.
check it in - PDT+
Whiteboard: PDT,[correctness] → PDT+,[correctness]
Checked in on branch
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Verified with 20010926 0.9.4 builds on Wins 2K, NT, Linux and MacOS X.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.