Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#12271 closed bug (fixed)

Printing crashes application in BPrivate::PrintServerMessenger::RejectUserInput()

Reported by: diver Owned by: axeld
Priority: normal Milestone: Unscheduled
Component: Kits Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by jackburton)

hrev49491. Trying to print or doing page setup from any app causes a crash: for example, Showimage: File->Print... crash.

0x79771880	0xe947a3	BPrivate::PrintServerMessenger::RejectUserInput() + 0x87 
0x797718b0	0xe94696	__Q28BPrivate20PrintServerMessengerUlP8BMessage + 0x42 
0x79771900	0xe927df	BPrintJob::ConfigJob() + 0x2b 
0x79771ad0	0x120f7cc	ShowImageWindow::_PrepareForPrint() + 0x48 
0x79771bc0	0x120d81b	ShowImageWindow::MessageReceived(BMessage*) + 0x123f 
0x79771bf0	0xe07a99	BLooper::DispatchMessage(BMessage*, BHandler*) + 0x59 
0x79771dd0	0xee7be0	BWindow::DispatchMessage(BMessage*, BHandler*) + 0x176c 
0x79771e30	0xeebbd2	BWindow::task_looper() + 0x28e 
0x79771e60	0xe08f41	BLooper::_task0_(void*) + 0x3d 
0x79771e88	0x2700c7d	thread_entry + 0x21 
00000000	0x609a0250	commpage_thread_exit + 0

Attachments (1) (24.9 KB ) - added by diver 5 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 by jackburton, 5 years ago

StyledEdit crashes with the same stack trace

comment:2 by jackburton, 5 years ago

Description: modified (diff)
Summary: [ShowImage] crashes in BPrivate::PrintServerMessenger::RejectUserInput()Printing crashes application in BPrivate::PrintServerMessenger::RejectUserInput()

comment:3 by jackburton, 5 years ago

Could be a regression caused by the launch daemon ?

comment:4 by diver, 5 years ago

Maybe the crash in PrintServerMessenger::RejectUserInput() is related to hrev49481?

in reply to:  4 comment:5 by jackburton, 5 years ago

Replying to diver:

Maybe the crash in PrintServerMessenger::RejectUserInput() is related to hrev49481?

Yeah, that seems a better candidate than the introduction of the launch_daemon

comment:6 by jackburton, 5 years ago

From a cursory look, one problem seems to be that the window default button is set in BAlert::Go(), while it was set in the constructor before. Since this code dereference DefaultButton() without checking for NULL, this might very well be the cause of the crash.

comment:7 by jackburton, 5 years ago

Adding the following code:

if (CountButtons() > 0)
		SetDefaultButton(ButtonAt(CountButtons() - 1));

to the end of BAlert::_Init() fixes the crash. Although now we have a nice BAlert shown on the screen. I admit the code in there is sort of a hack, since it creates a BAlert and moves it out of the screen to hide it and block user input.

comment:8 by diver, 5 years ago

Owner: changed from nobody to axeld
Status: newassigned

comment:9 by jackburton, 5 years ago

Resolution: fixed
Status: assignedclosed

Diver, thanks for the hint. It's fixed in hrev49596, although :

  1. The code in there doesn't look nice.
  2. The changes in hrev49481 could still cause other problems, since it's an API behaviour change.

comment:10 by jessicah, 5 years ago

With the changes to BAlert, wouldn't it be simpler (and less API breakage) to move the call to SetDefaultButton(ButtonAt(CountButtons() - 1)) inside BAlert::_Prepare() into the new BAlert::AddButton() function? E.g.

BAlert::AddButton(const char* label, char key)

Given that the API documentation states that the last button is, by convention, the default button, and this always creates a new last button, it will automatically set up the default button correctly, as AddButton() is called from _Init() and the existing non-default constructors.

This would remove the hack introduced in hrev49596 for the default button, and avoid possible crashes in other uses of the originally documented BAlert API.

Note: See TracTickets for help on using tickets.