Opened 5 years ago

Last modified 4 years ago

#274 reopened enhancement

Add EXCEPTQ support

Reported by: dmik Owned by:
Priority: normal Milestone: libc-1.1
Component: libc-backend Version:
Severity: normal Keywords:
Cc: stevenhl


There is a nice EXCEPTQ library that catches fatal system exceptions and prints out a nice trap report (that contains a lot of useful information such as disassembly, call stack and symbols, labels on stack etc). This is extremely useful when debugging application crashes — especially in the absence of modern debuggers.

Another good feature of EXCEPTQ is that it has its own debug symbol file format (XQS) that overcomes limitations of the traditional mapsym tool regarding the maximum number of symbols. When generating reports it understands all possible ones though: embedded info, .SYM, .DBG.

In order to use EXCEPTQ in the application, it's necessary to explicitly install it on each thread the application creates. In case of big applications (like Firefox) it turns out to be a problem as there are many places where threads are created (directly through beginthread I mean).

So my suggestion is to do it in the kLIBC thread function wrapper where it installs its own exception handlers. It may be done dynamically, i.e. only if EXCEPTQ.DLL is present (and if not disabled in the process environment). Also, a new -Z option may be introduced to make EXCEPTQ support optional on per-application basis.

Here is the recent version:

Change History (7)

comment:1 Changed 5 years ago by ydario

  • Milestone set to libc-0.6.6

comment:2 Changed 5 years ago by dmik

Instead of adding a new -Z option, it makes more sense to use the already existing LIBC_PANIC environment variable and add a new value to it (exceptq/EXCEPTQ), see source:/branches/libc-0.6/src/emx/src/lib/sys/b_panic.c?rev=3370#L191.

More over, I think that we may make exceptq the default value (instead of verbose) when EXCEPTQ.DLL is detected on the system.

In either case, the change is rather trivial.

comment:3 Changed 5 years ago by bird

  • Resolution set to wontfix
  • Status changed from new to closed

Sorry, while the thing might be useful for someone, it's unfortunately closed source, the header is of unknown license, the binaries are also of unknown license, and I don't want external dependencies like this. Not gonna happen.

comment:4 Changed 5 years ago by stevenhl

  • Cc stevenhl added

comment:5 Changed 5 years ago by stevenhl

The exceptq that Rich or I distribute have never been closed source.

The original except and exceptq packages developed by Marc Fiammante and others were marked IBM Internal and were effectively closed source even though copies showed up here and there on the web. In 1996, IBM released the exceptq package as sample code in DevCon V1R12.. DevCon sample code is covered the by the DevCon license which allows sample code to be freely modified and distributed.

The exceptq packages that Rich or I distribute are based on the the DevCon sample code.

The sources probably should have the copyright attributions updated to match the DevCon? license requirements. However, the sources released by IBM had no IBM copyright notations and both Rich and I neglected to add them. This is easy enough to rectify. The sources should probably also include license terms to avoid questions. A Mozilla style license or a GPL license is fine with me unless someone has a better idea.

comment:6 Changed 5 years ago by dmik

  • Resolution wontfix deleted
  • Status changed from closed to reopened

This should be resurrected and still included in 0.6.6 I think. As Steven wrote it has never been closed source and there is no link or compile time dependency if you load EXCEPTQ.DLL dynamically. Very easy to insert. Very useful for all applications at once (including LIBC itself). Much more helpful than LIBC panic or its tiny SIG* report. See also #296.

comment:7 Changed 4 years ago by bird

  • Component changed from libc to libc-backend
  • Milestone changed from libc-0.6.6 to libc-1.1

DevCon? license isn't very open, any kind of linking with GPL code is out of the question. But that's beside the point. As stated in comment 3 I'm not too keen on this feature. So, please do not expect me to write any code for this, nor expect me to consider patches that loads EXCEPTQ.DLL by default (think about shell script (like configure) and assembler/compiler performance) - patches that slows down kLibC initialization even a little or will be rejected.

This will _not_ happen for 0.6.6 (even If I get a good patch).

Note: See TracTickets for help on using tickets.