Opened 12 years ago

Closed 12 years ago

#171 closed defect (wontfix)

Use POPUPLOG.OS2 mechanism in newer libc

Reported by: guest Owned by: bird
Priority: normal Milestone:
Component: libc-backend Version:
Severity: normal Keywords:
Cc: mozilla@…

Description

OS/2 programs that crash write information to <DRIVE>:\POPUPLOG.OS2 if SUPRESSPOPUPS=<DRIVE> is set in Config.sys (which on most installations of OS/2 and eCS seems to be the case). This mechanism also worked in programs linked with libc 0.5.x but not any more when linked against libc 0.6.x.

This is bad because users are used to look in POPUPLOG.OS2 if a program disappears. The information logged in those crash screens is also well documented in the OS/2 debugging guide (?) and so this may give hints for developers of these programs. Even though more capable mechanisms exist for this, many users are not set up to take e.g. program dumps. And while libc 0.6.x programs still output crash information to the console, most users (or GUI programs) will not see this, so to it appears that the program just vanished for no reason.

(This was already some time ago discussed on the libc list/newsgroup but never opened this as a ticket.)

Change History (1)

comment:1 Changed 12 years ago by bird

  • Component changed from baselayout to libc-backend
  • Resolution set to wontfix
  • Status changed from new to closed

I'm not sure what SUPRESSPOPUPS has to do with the way libc deals with unhandled signals really and I'm not entirely sure which discussions you're referring to here.

The signal implementation in kLIBC will terminate the process according to the standard signal behavior, and will terminate the process itself in order to avoid potential trouble (deadlocks and what not) and to offer more options to you as a developer. Like process dumps, breakpoints when debugging.

It is true that the current output from kLIBC in these panic situations is kind of useless, but the popuplog entry isn't much more useful either imho. But, at least two persons has been working on extending the kLIBC panic output with detailed information about call stacks and such. This is the solution I want. That said, neither of them have sent me any patches yet... If I don't get any, I'll implement it myself for 0.7 or 0.8.

Note: See TracTickets for help on using tickets.