[clug] Reading strace output

[steve jenkin]

Carlo Hamalainen wrote on 14/05/10 11:38 AM:
> Hi,
> 
> I'm having trouble with an ODBC connection to an Intersystems Cache
> database. Every few days I am unable to connect, whether I try pyodbc
> or isql from unixodbc directly. I'm using the ODBC driver from
> Intersystems.

<snip>

> Then there are a bazillion brk() lines and isql tries to use all
> available memory. I'm only surviving because I use ulimit to cap
> memory usage at 500Mb.

Sorry, I only read the 'headline' [unable to connect] and missed that
you already knew it was an Out-of-Memory fault.
[Newspapers call this 'burying the lead']

Sorry to waste your time [and the list's].

> Does this look like a standard C/C++ pointer problem? And is it likely
> that the bug is in the odbc driver?

Sorry, can't help.
I've run systems with memory leaks in important daemons. It rankles, but
restart with cron in your least-busy-period is a useful "work around".
Ameliorates the problem and buys you time to properly diagnose the fault
and get the vendor to fix it...

> Are there any other tools I can try to narrow down the problem further?


Best generic tool is *reproducing* the fault on demand.
When you can do that, even if it takes 2-3 days, you have a shot of
sneaking up on the fault slowly (& inspecting everything in that mode)
and poke around to see just where the fault lies.
Or if some more recent or different release has a different bug-set that
avoids this problem.

Do you have a test system you can torture and can do this?
The best thing with a test system is you can control the load and its
timing - so it doesn't interfere with production response times or cause
other problems.

How important is the fault to you??
[A 'drop-dead' or annoyance?]

HTH
s



-- 
Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA

stevej098 at gmail.com http://members.tip.net.au/~sjenkin