Wt

Hey Dottor,

Indeed that is an annoying problem. I see two things that can provide extra context for this error: the string that caused it, and the stack trace. And indeed, it should be configurable if you print it or not.

Short quickfix on Linux in the meantime is to print Wt::backtrace() (#include "Wt/WException") and if desired the contents of the string where the error is printed. Long-term solution is to post a feature request to support this on Linux+Windows ;-)

Wim.

Thanks for the reply.

Sadly I cannot easily find the line of code which creates the string that generates this error, so I cannot check the "guilty" string itself.

I've given a look to Wt/WException, but it doesn't seem to include a Wt::backtrace. Probably I have to update my wt to a newer version, at this point. (Even if I must add that I failed to find it even in the online documentation).

The backtrace in itself, anyway, is not such a big problem: I've my own code (created ages ago... one of the first things I've done when I started to write big pieces of code which might have been difficult to debug) which can print semi-readable stack, the problem is that I don't know where to call this, since I don't know where the error happens.

At this point it seems that the only real solution for now is the old and dirty: "comment out every piece of code you suspect of being guilty, then uncomment them step by step and try to find which part generates the error".

Which is still feasible for now, but obviously will not when (if) the program goes online, if some error (even generated for some other reason) happens.

Thanks again. :)

If you want to know where exactly this error is generated, it is in src/web/XSSFilter.C. If you compile Wt with libunwind, then you can use Wt::backtrace() (from the header Wt/WException) there to retrieve the backtrace.

Thank to you too, Roel.

Yes, probably when I will complile again Wt I will try this, more for the future, since for now I've fixed the specific problem with the "old and dirty" tecnique. ;)