dialog call to SetInt is winding up in GetInt

VERIFIED DUPLICATE of bug 12133

Status

P3
normal
VERIFIED DUPLICATE of bug 12133
19 years ago
2 years ago

People

(Reporter: morse, Assigned: davidm)

Tracking

Trunk
x86
Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
- enter browser
- go to http://scopus/bugsplat/login.html (or any other login form)
- type some characters in the username and password fields
- press the "signon" button
- answer yes to the question about saving the password

You will crash with the stack trace shown below.  Note that the last line is in
nsDialogParamBlock::GetInt but you got to it from a SetInt call in
nsCommonDialogs::PromptPassword.

nsDialogParamBlock::GetInt(nsDialogParamBlock * const 0x03500d50, int 2, int *
0x00000002) line 84 + 13 bytes
nsCommonDialogs::PromptPassword(nsCommonDialogs * const 0x035012b0, nsIDOMWindow
* 0x02611e38, const unsigned short * 0x03501330, unsigned short * * 0x0012dfd4,
int * 0x0012dff4) line 213
nsNetSupportDialog::PromptPassword(nsNetSupportDialog * const 0x030a4920, const
unsigned short * 0x03501330, unsigned short * * 0x0012dfd4, int * 0x0012dff4)
line 589 + 44 bytes
wallet_GetString(char * 0x035010f0) line 828 + 30 bytes
Wallet_SetKey(int 0) line 1154 + 9 bytes
si_SetKey() line 332 + 7 bytes
si_SaveSignonDataLocked(int 1) line 1738 + 5 bytes
si_PutData(char * 0x03063030, LO_FormSubmitData_struct * 0x0012e300, int 1) line
1469 + 7 bytes
SINGSIGN_RememberSignonData(char * 0x03063030, char * * 0x0012e53c, char * *
0x0012ed14, char * * 0x0012f4e4, int 3) line 1958 + 15 bytes
WLLT_OnSubmit(nsIContent * 0x02d35410) line 2759 + 37 bytes
nsWalletlibService::Notify(nsWalletlibService * const 0x023af658, nsIContent *
0x02d35410) line 181 + 9 bytes
nsFormFrame::OnSubmit(nsFormFrame * const 0x03046b88, nsIPresContext *
0x02bf9670, nsIFrame * 0x030545b0) line 455
nsImageControlFrame::MouseClicked(nsIPresContext * 0x02bf9670) line 404
nsImageControlFrame::HandleEvent(nsImageControlFrame * const 0x030545b0,
nsIPresContext & {...}, nsGUIEvent * 0x0012fba0, nsEventStatus &
nsEventStatus_eIgnore) line 259
PresShell::HandleEvent(PresShell * const 0x02d22dc4, nsIView * 0x0305b480,
nsGUIEvent * 0x0012fba0, nsEventStatus & nsEventStatus_eIgnore) line 1877 + 38
bytes
nsView::HandleEvent(nsView * const 0x0305b480, nsGUIEvent * 0x0012fba0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 835
nsView::HandleEvent(nsView * const 0x02d23120, nsGUIEvent * 0x0012fba0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 820
nsView::HandleEvent(nsView * const 0x02d26130, nsGUIEvent * 0x0012fba0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 820
nsView::HandleEvent(nsView * const 0x02d261c0, nsGUIEvent * 0x0012fba0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 820
nsView::HandleEvent(nsView * const 0x02d23620, nsGUIEvent * 0x0012fba0, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore, int & 0) line 820
nsViewManager::DispatchEvent(nsViewManager * const 0x02d239e0, nsGUIEvent *
0x0012fba0, nsEventStatus & nsEventStatus_eIgnore) line 1611
HandleEvent(nsGUIEvent * 0x0012fba0) line 67
nsWindow::DispatchEvent(nsWindow * const 0x02d27c04, nsGUIEvent * 0x0012fba0,
nsEventStatus & nsEventStatus_eIgnore) line 498 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fba0) line 523
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3271 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
3466
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 17170754, long *
0x0012fdd4) line 2539 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x02320440, unsigned int 514, unsigned int 0, long
17170754) line 571 + 27 bytes
USER32! 77e71268()
NECKO! unsigned int  depth + 943910 bytes
(Reporter)

Updated

19 years ago
Blocks: 12137

Comment 1

19 years ago
I dont see this on unix. I get the dialogs ok and I quit.

Steve usually whenever I get this kind of one fn. calling another, it must be
the vtable is screwed up. And that can happen if one part of the tree was built
with a different header than the other, and the header changed recentely.

Did you do a clobber build. I will try this on my windows too once I am done
building.

Comment 2

19 years ago
Aggh I meant, I get the two dialogs of enabling singlesignon and saving the
password ok. (I dont know why I said quit in the previous add).
(Reporter)

Comment 3

19 years ago
This is a build using a brand new tree.

I just spoke with Waterson and he is also not seeing this problem.  What we are
suspecting is that my symlink is screwed up.  I have many old trees (which I
rename) and I think I am linked to one of the old dists.  I'm deleting all old
trees right now and will see if that clears it up.

BTW, the problem is not in the two dialogs for enabling signon.  The crash comes
when it tries to display a third dialog -- the one that prompts for the database
key.  I don't get to that window

Comment 4

19 years ago
I'm seeing this exact same problem under different circumstances, on my Linux box.  There's only
one tree on that machine, and it was completely destroyed and rebuilt from scratch this morning.

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 5

19 years ago
Same as bug 12133.  Pull nsDialogParamBlock.cpp rev 1.8 to fix.


*** This bug has been marked as a duplicate of 12133 ***

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 6

19 years ago
So I wasn't crazy after all.  But how come neither dp nor waterson had the
problem?
(Reporter)

Updated

19 years ago
Blocks: 7530

Comment 7

19 years ago
Changing component to Browser-General. (HTML Dialogs is going away, and this bug 
doesn't look suitable for XP Apps on quick glance.)
Component: HTML Dialogs → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.