[clug] Reading strace output

Carlo Hamalainen carlo.hamalainen at gmail.com
Thu May 13 19:38:13 MDT 2010


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.

Running strace seems to give some clue:

$ strace isql MYDSNNAME

<snip>

connect(3, {sa_family=AF_INET, sin_port=htons(1972),
sin_addr=inet_addr("192.xxx.xxx.xxx")}, 16) = -1 EINPROGRESS
(Operation now in progress)
select(4, [3], [3], NULL, {10, 0})      = 1 (out [3], left {9, 967025})
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
send(3, "\2\0\0\0\1\0\0\0\0\0\0\0HS0\0"..., 16, 0) = 16
recv(3, 0x88af8cc, 14, 0)               = -1 EAGAIN (Resource
temporarily unavailable)
select(4, [3], NULL, NULL, {10, 0})     = 1 (in [3], left {9, 951142})
recv(3, "\r\0\0\0\1\0\0\0\0\0\0\0\0\0"..., 14, 0) = 14
recv(3, "-\0\1\0\t\1Unicode"..., 13, 0) = 13
open("/home/carlo/.odbc.ini", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0660, st_size=2533, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb757d000
read(4, "[ODBC Data Sources]\nSamples = Sam"..., 4096) = 2533
close(4)                                = 0
munmap(0xb757d000, 4096)                = 0
send(3, "\211\0\0\0\2\0\0\0\0\0\0\0CN\n\2U\0S\0E\0R\0\20\2]\0|\0\276\0\376"...,
151, 0) = 151
recv(3, 0x88af8cc, 14, 0)               = -1 EAGAIN (Resource
temporarily unavailable)
select(4, [3], NULL, NULL, {10, 0})     = 1 (in [3], left {4, 970780})
recv(3, "\17\0\0\0\2\0\0\0\0\0\0\0\241\1"..., 14, 0) = 14
recv(3, "\17\1Access Denied"..., 15, 0) = 15
close(3)                                = 0
brk(0x88dc000)                          = 0x88dc000
brk(0x88fd000)                          = 0x88fd000
brk(0x891e000)                          = 0x891e000
brk(0x891d000)                          = 0x891d000
brk(0x893e000)                          = 0x893e000
brk(0x893d000)                          = 0x893d000
brk(0x895e000)                          = 0x895e000
brk(0x897f000)                          = 0x897f000
brk(0x89a0000)                          = 0x89a0000

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.

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

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

-- 
Carlo Hamalainen
http://carlo-hamalainen.net


More information about the linux mailing list