Problem with mysql api calls.

jwl_at_sgi.com
Date: 08/23/04


Date: Mon, 23 Aug 2004 16:03:20 -0400

I'm having a problem with a bit of code that I have "adopted". It was
partially complete when I took it over. The function of the code is to
read a log file, locate files described in that log file and fill in a
few tables in a couple of MySql databases. The program is using a
number of std objects, hashmaps, linklists, vectors etc. It makes
direct calls to the MySql api. The version of MySql is 3.23.58.
Redhat 9, g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) on a Intel
IA32 system.

The problem is that after some number of transactions, the call to
connect to the server fails with the error:
Can't create TCP/IP socket (24)

I did a Google search for that error message and nothing came up that
seemed to fit.

I was able to aggrevate the situation by adding a heartbeat update that
simply put the current date in a table periodically. If I set the
interval short, to one minute, it would fail in a couple of hours. If I
bumped it up to 10 minutes, it took 2.5 days to fail. So I moved that
code to a completely separate process, via a fork call. It didn't
improve anything.

I have integrated the Electric Fence library into the program and set
all the various options to try to catch malloc problems. I found one,
but fixing it didn't have any effect on the failure.

I'm not looking for a solution but ideas on where to go next to isolate
the failure. I belive the failure is a symptom of the problem and not
the problem itself. During previous attempts to find the problem I
found the open of the log file would fail after a number of successful
attempts. And it is the total number of transactions that seems to
give me the trouble, but it doesn't really care which of the two
databases that I'm accessing/updating, it's just the total number. In
fact the heartbeat update is being done to one and the failure is on the
other one.

Any suggestions as to what I might do? Any ideas on tools that might
tell me what's up? I forgot to mention this is a muli-threaded app. 7
threads running, mostly in a sleep state. CPU load is very low. All
the threads are started at the beginning and are not recreated.
Changing the code to open DB once and update many times, vs open
everytime we update had no effect.

Thanks for any assistance.

Jim.



Relevant Pages

  • Re: Thread Pre-Emption Question . . .
    ... Not checking for failure of InitializeCriticalSection, ... not checking deallocateor failure is okay because the program will continue to run correctly although it is good practice to check this in debug builds because deallocators usually only fail because of invalid arguments. ... the correct execution of error handling logic (if the access causes unplanned exceptions before data corruption and these unplanned exceptions are caught in the same place as planned exceptions for example). ... This can, and will, corrupt real data in any number of random ways depending on the work done in the writer. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Thread Pre-Emption Question . . .
    ... Not checking for failure of InitializeCriticalSection, ... not checking deallocateor failure is okay because the program will continue to run correctly although it is good practice to check this in debug builds because deallocators usually only fail because of invalid arguments. ... correct execution of error handling logic (if the access causes unplanned exceptions before data corruption and these unplanned exceptions are caught in the same place as planned exceptions for example). ... This can, and will, corrupt real data in any number of random ways depending on the work done in the writer. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Importance of Failure
    ... Very few people really think that progress happens without failure. ... You got game. ... look at how frequently you fail! ... You have to convince the world you're right (which you ...
    (sci.math)
  • Re: Importance of Failure
    ... Very few people really think that progress happens without failure. ... You got game. ... look at how frequently you fail! ... You have to convince the world you're right (which you ...
    (sci.crypt)
  • Re: quality control
    ... Almost always, zero. ... will be, on the average, only 1 bad item in 100 samplings -- ... You expect 1 failure in 10,000. ... I'm thinking with the binary outcome of fail/not fail, ...
    (sci.stat.math)