pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedOdd program behaviour
3+ messages / 3 participants
[nested] [flat]
* Odd program behaviour
@ 1999-03-07 23:44 James Thompson <jamest@math.ksu.edu>
1999-03-08 07:29 ` Re: [INTERFACES] Odd program behaviour Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: James Thompson @ 1999-03-07 23:44 UTC (permalink / raw)
To: pgsql-interfaces; pgsql-general@postgreSQL.org; swig@cs.utah.edu
I'm desperate here. I've got two days invested in this and have not made
any progress at all. I'm hoping someone has run into the following and
might be able to give me a clue.
I have a a bunch of C functions that access the database via ecpg.
I have used SWIG to wrap these functions so that they may used in TCL/TK
I have the front end written in TCL/TK.
Everything works fine when saving data but pulling data from the database
results in a segfault when using the TCL/TK front end. The same functions
work fine when called from a C test program. In addition the
customer_create function listed in the backtrace is used alot in the front
end without problems. It only seems to bomb when I'm actively fetching
data from the database.
A backtrace on the core file gives me this.
#0 0x40248090 in ?? () from /lib/libc.so.6
#1 0x40247fa5 in ?? () from /lib/libc.so.6
#2 0x804ec5a in obmalloc (size=84) at memory.c:28
#3 0x804c896 in customer_create () at customer.ec:73
#4 0x8049ce2 in packet_create () at packet.ec:78
#5 0x804c475 in packet_query (object=0x80ecb60) at packet.ec:795
#6 0x80512c2 in _wrap_packet_query (clientData=0x0, interp=0x8058d~b8,
objc=2, objv=0x8059a48) at obe_wrap.c:1818
#7 0x400ca467 in ?? () from /usr/local/lib/libtcl.so
Now I'm fairly new to gdb but this looks like it's dying inside the
obmalloc which is simply...
obmalloc(size_t size)
{
void *tmp;
assert(size!=0);
tmp = malloc(size);
while (tmp == NULL) {
fprintf(stderr, "obmalloc: memory exhausted. 2 second delay before
retry");
sleep(2);
tmp = malloc(size);
}
return tmp;
}
I'm at the point that I can't think straight anymore. Does anyone have a
suggestion on why the code would work correctly from C but not TCL?
Oh, and if you wan't more info on what I'm trying to do visit
www.math.ksu.edu/~jamest/obe
I'd be willing to move the code up now if anyone wants to look at it.
I've mangled it up enough this weekedn it's probably good for a laugh.
Thanks in advance for any ideas you can provide.
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [INTERFACES] Odd program behaviour
1999-03-07 23:44 Odd program behaviour James Thompson <jamest@math.ksu.edu>
@ 1999-03-08 07:29 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 1999-03-08 07:29 UTC (permalink / raw)
To: James Thompson <jamest@math.ksu.edu>; +Cc: pgsql-interfaces
James Thompson <jamest@math.ksu.edu> writes:
> I'm desperate here. I've got two days invested in this and have not made
> any progress at all. I'm hoping someone has run into the following and
> might be able to give me a clue.
> Everything works fine when saving data but pulling data from the database
> results in a segfault when using the TCL/TK front end.
> [ segfault is evidently inside malloc ]
A fairly reliable rule is that a segfault inside malloc means your
program has trodden on malloc's data structures that keep track of free
and allocated space in the malloc arena. Usually this means you have
written off the end of a chunk of malloc'd space. (Whether this is a
bug in the code that calculated the amount of space to ask for or a bug
in the code using the space is for you to say, of course.)
If you don't have any direct insights into the problem, I'd suggest
building your app with a debugging malloc package that will detect
the corruption as soon as possible. One I've had good luck with
for apps that don't require huge amounts of space is Electric Fence.
(No URL at hand, but poke around the web and you should find it.)
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Odd program behaviour
@ 1999-03-08 22:31 Jim Lawson <jrl@msbit.com>
0 siblings, 0 replies; 3+ messages in thread
From: jrl@msbit.com @ 1999-03-08 22:31 UTC (permalink / raw)
To: pgsql-interfaces@hub.org; +Cc: James@msbit.com, Thompson@msbit.com, <jamest@math.ksu.edu>
We ran into similar problems integrating a third party library into a perl
application with SWIG. There appeared to be some confusion between perl and
SWIG over references/pointers and allocating memory for the referred/pointed to
object. We worked around the problem by making sure the memory allocation
happened in perl (by initializing the reference with a suitably large object).
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~1999-03-08 22:31 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-03-07 23:44 Odd program behaviour James Thompson <jamest@math.ksu.edu>
1999-03-08 07:29 ` Tom Lane <tgl@sss.pgh.pa.us>
1999-03-08 22:31 Re: Odd program behaviour Jim Lawson <jrl@msbit.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox