I've some new info on this.

First of all, the problem now occurs on some x86 machines where the
official build of the latest FB 2.1 is installed so it's not a SPARC
specific issue, nor it's a buggy build.

About the memory usage. I ran "vmstat 2" and this is what it showed:

kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m1 m1 m2 m2 in sy cs us sy id
0 0 61 13775400 1640744 0 0 0 0 0 0 0 0 0 0 0 542 103 278 0 0 100
0 0 61 13775400 1640744 0 0 0 0 0 0 0 2 2 0 0 607 1613 1315 1 1 98
0 0 61 13775400 1640736 0 0 4 0 0 0 0 0 0 0 0 627 2611 1974 1 2 97
0 0 61 12816584 683856 67 3466 55 0 0 0 0 5 5 0 0 644 26469 880 5 91 4
3 0 61 11229888 58512 0 12676 4 750 788 0 40197 0 0 5 5 573 18122 533 6 84 10
6 0 61 10902720 13672 14 1337 40 8084 12716 0 128316 2 2 69 69 846
2004 460 1 45 54
2 0 61 10808512 10776 31 559 92 6452 7204 0 127719 8 8 57 57 881 3613
2432 1 29 69
0 0 61 10755264 10456 13 550 204 7324 7548 0 128388 21 21 60 60 920
2315 1578 1 28 71
3 0 61 10728584 9560 35 200 211 6555 6702 0 123426 35 35 51 51 905
1361 1160 1 36 63
6 0 61 10716248 10872 15 55 140 6081 6588 0 128072 15 15 54 54 845
303 554 0 26 74

The 4th line is where isql was started. After this, free was around
10k while swap was continuously decreasing. My guess is that when the
swap runs out, isql will get segfault.

Right now I'm attempting to get a core dump of isql while it's
running, or get some useful information from truss.

Take care,
Jarek