eCAP

How to handle exceptions thrown by adapter libraries?

Asked by Christof Gerber

I am calling a custom third party library from my eCAP adapter which is plugged to squid. This library throws exceptions upon errors. When an exception happens Squid crashes ( "FATAL: Received Segment Violation...dying"). The exact same library call throws an exception which can be catched smoothly when I run a dedicated c++ program for this task (outside of eCAP). What is wrong here? Might there be something in eCAP or Squid that pre-catches the exception which leads then to the memory-violation? Or should eCAP and std::exceptions work and I am missing something else?

Question information

Language:
English Edit question
Status:
Solved
For:
eCAP Edit question
Assignee:
No assignee Edit question
Solved by:
Christof Gerber
Solved:
Last query:
Last reply:
Revision history for this message
Alex Rousskov (rousskov) said : 		#1

Good question, thank you!

Adapters should be written using exception-safe code, especially adapters that use exception throwing libraries.

Ideally, the host application should handle any adapter exception without crashing. In your specific case, Squid probably handles service configuration exceptions well, but I see no code dedicated to eCAP transaction exceptions. That means that any eCAP transaction exception that leaves the adapter will be handled by generic Squid exception handling code. That code works OK in some contexts, but Squid may crash if an exception is thrown in (many) other contexts -- a lot of Squid code is not exception safe yet. Squid v5 exception handling is better than Squid v4 exception handling. Squid v4 exception handling is better than Squid v3 exception handling.

Going forward, if you want Squid to handle the adapter-originating exception, but your Squid crashes, then you should file a Squid bug report. I recommend attaching a simple/minimal adapter that can easily reproduce the problem without the use of any 3rd party libraries (the sample adapter itself will throw an exception, probably on every transaction). Posting a stack trace from the segmentation fault and ALL,9 cache.log is also a good idea. Depending on the nature of the problem and the Squid version, it may be possible to fix the crash without doing a lot of Squid development. However, some exception-handling bugs are very difficult to fix properly. YMMV.

Meanwhile, you can probably bypass the problem using try/catch blocks in your adapter code (where the throwing library calls are made).

Please see the following new FAQ that has more details related to your question:
FAQ #2945: “How does eCAP deal with C++ exceptions?”.

Revision history for this message
Christof Gerber (sitschi) said : 		#2

Thanks. My problem is solved. It was a memory issue and therefore improper exception handling. Exception handling within my eCAP adapter seem to work well now.