I have created a Multhreaded Application in Pro*C \(using pthreads\) with about 5 Threads running simultaneously. The Application is basically to Update a Centralized Table in Oracle, which updates different rows in the Table \(Each Thread updates different rows!\). The problem is that it gets compiled and when I execute, I get an error.
This happens like this ...
void *thread_1(void *nothing)
{
EXEC SQL BEGIN DECLARE SECTION;
.
.
.
EXEC SQL END DECLARE SECTION;
EXEC SQL CONTEXT USE :ctx0;
EXEC SQL WHENEVER SQLERROR DO sql_error\(\);
printf\(" In Here\\n"\);
EXEC SQL CONNECT : uid IDENTIFIED BY : pwd;
printf\(" Out Here\\n"\);
.
.
.
}
The "In Here" is displayed on the Screen, but "Out Here" message is never shown on screen, but instead, I get the message:
In Here
Stack overflow: pid 17041, proc UPDATE, addr 0x140065ff0, pc 0x1200b961c
Memory fault(coredump)
The UID/PWD is right. But when I reduse some "EXEC SQL ..." statements from the function, the program works perfecty fine!
Could someone tell me what exactly is the error and how can it be avoided.
No, its not necessary that you pass the sql_context to the function thread_1, and i've already written earlier, it works perfectly fine when i remove some 'EXEC SQL ...' statements. its probably got to do with some compiler options.
Stack overflow, I. declaration size of your stack is small, may be you should increase it.
Coredump , sometimes it appears when you try to compile and you had already made *.o etc which we could say has formed a file called core .Sometimes you have to delete them and then compile afresh.
I think the first thing you want to do is to
examine the core file using a debugger. The
debugger you use will depend on the compiler
tools you are using. For instance, if you are
using gcc/g++ you can debug using gdb. Using
gdb, you can load the program executable
along with the core file and run the "bt"
(backtrace) command to find exactly where the
program is failing. It would be better to have
the program compiled using the "-g" (for gcc)
option so that a symbol table is created so you
can follow the program execution in a very
detailed manner.
If you are not using the GNU compiler/debugger
then you'll have to find out what debugger
you have on your system (i.e. ladebug, dbx, sdb,
adb, etc...)
On increasing the stack size, you will have to
check your compiler documentation as this is
very compiler dependent.
Can you please suggest any documentation explaining how to use these various debuggers. I am having a wild goose-chase trying to find the source of a memory fault that happens on our customers, but I cannot imitate it on my own development machine. I now have a core dump, but I need to know what to do with it.
...It would be best to actually debug it on the
customer machine if possible but I understand
that that is not always doable. You will also
need the actual executable that they are running
as well unless you can build what they have.
I assume that your development
environment is at least the same (i.e. same
type of UNIX on same type of hardware - RISC, etc)
Assuming this was built for a production
environment, I would expect that it was not
compiled with symbol tables (i.e. "-g" option).
It may help to build them a new version with
this option on and install it on their system
and duplicate the core dump then use the new
core with the new executable. The information
you get will be much more "readable" and will
"map" to your source code much more easily.
We are running sco, and using the compiler that comes along with it. I recomplied the program with the -g flag, but we have already updated the effected program, so I will now need to wait till it happens again.
So, the next time the customer gets a memory fault, I will copy the core dump to my machine and I will try to debug. The question is which debugger to use, since I don't think gdb will work if we don't use gcc. I have heard about adb and dbx, but I don;t know how to use either of them.
This matter has become of great urgency to me. I got a new core dump today, and I need to analyze it. I am using dbx, and I see that one element in my array is blank even though it should contain data valid data, and this is the source to our program bombing out.
The question is, using the core and dbx can I get a trace of every time this array was refferenced and/or modified. Do I need a different debugger? If the core isn't enough, is there a different method to get a trace of my program?
Another big problem is that this oly happens on the customer';s machine, I cannot replicate it on my dev machine. And even worse, when I dial in to the customer I cannot reproduce it either?
If you have any suggestions I would greatly appreciate ie.
dbx should work for you. You can even
execute the program via dbx and set break points
to allow you to step through the segment of code
and "watch" the variable in question. However,
multithreaded programs tend to be more difficult
to "step" through and in many cases that I have
observed personally, the code will not fail
when executed from the debugger
I would recommend a couple of things...
I would first add signal handling to catch
the signal (I assume you are getting a SEGV or
Segmentation fault type of error). This will
at least allow you to "control" the fault
detection to allow your program to "clean up"
then you can all "abort()" to dump a core image
if you like. Also, I would go to the
"old fashioned" way of what I like to call
"brute force" debugging. I would add logging
code around the sections of code that assign
values to this variable (be sure to "flush()" the
output to the log before moving on to the next
statement). Also, make sure that the Oracle
libraries and any shared libraries that you use
on the production machine are the same version
as your development environment.
Another thing to try, is if you can build the
code completely with "static" libraries, do that.
It may also help to post the "exact" system
error message. I assuming it's a SEGV error
which typically indicates stack corruption which
can easily happen if the bounds of an array are
exceeded but seeing the error would verify this
assumption.
