When Web Crossing crashes it's possible that the only way to determine the problem will be by obtaining a stack trace. A stack trace tells our developers exactly what Web Crossing was doing at the instant of the crash. Obtaining a stack trace is a bit different on various operating systems.
Windows Windows will generate a stack trace automatically if the Dr. Watson program is configured appropriately and is useful only when a "debug" version of Web Crossing with full debugging symbols is installed. Since debugging versions are much larger than standard versions this will require installing a special build.
Unix/OSX On Unix users can install the freeware gdb (Gnu debugger) program and generate a stack trace to send to us, or send us certain files so that we can generate the stack trace ourselves. If gdb is installed, do the following:
Start gdb like this: "gdb webx-go core" where "webx-go" is the name of the Web Crossing binary that created the core file (typically webx-go but users can change that) and "core" is the name of the core file (typically "core" on some systems and "webx-go.core" on others).
Type "info threads" to see the threads in operation. Note how many threads (1 through NN)
Type "thread 1"
Type "bt" for backtrace to get the trace.
Repeat steps "thread N" and "bt" for each thread number listed by the "info threads" command above, if applicable.
Type "quit" to exit gdb.
If gdb is not available, make a compressed tar archive containing webx-go, webx-log, and the core file and upload it to our ftp server. The exact binary that created the core file is required so it saves time if you provide it directly.