Tom-

This is really strange!
(Does that you feel better at all? :) )

The signal code is in there because MySQL does not care to be interrupted.
You can safely put it back.
The reason it was there is because this code was originally written for a
BBS which uses signals for IPC purposes.  MySQL wasn't impressed by that.
Most likely it can be removed. (Unless you have a signal handler!)

A few questions:

If you run the mud interactively (outside of a startup script) do any
messages go the the mud "console" when the write occurs?

What about the mysql log?  It can be really useful!

When you say "write" to the database, are you doing an insert, or an update?
(this could be important, and maybe not)

Another question, What version of MySQL are you running again?  The code
supplied only works with 3.23.x
If you are using this code with 4.x it will cause problems.  (you need to
switch around one of the data types.. not serious, but important)

After that is useless do this:

from 'area'>

gdb ../src/rom  <enter gdb>
gdb> set port 1234  (or whatever port you have designated to you)
(this next line depends on the insert or update.
if insert:
gdb> break send_query
if update:
gdb> break send_update
gdb> run

Now your mud starts.
Do whatever is it is you need to do to force the update or insert.
gdb will break.
Issue the 'next' command line by line and see where the mud pukes.
This might clue you into the problem, or maybe one of us if not.

Good luck!

>-----Original Message-----
>From: Tom Whiting [mailto:[EMAIL PROTECTED]
>Sent: Saturday, June 08, 2002 5:28 AM
>To: 'ROM'
>Subject: Advanced (kinda): Mysql & connection problems
>
>
>Greets,
>I've been here and there, trying like mad to get a persistent 
>connection
>to an SQL database the past few days, rather than connecting at will,
>and I've ALMOST got it. However, there's a few problems with it.
>
>The code I've been using is stuff that was contributed to the list a
>while back this year, and it works GREAT, except for the fact 
>that every
>time the mysql table is written to, it crashes the mud.
>
>It WRITES to the table just perfectly (I've got a front end that I use
>to go through entries every once in a while, so I can check that rather
>easily), but it's crashing the mud.
>
>Reading of the table is handled just wonderfully actually, no crashes
>whatsoever. The problem is writing to it, like something is still
>locked? Or it's trying to reload something yet failing or (?) I'm
>clueless here. To me, it would appear that this is a signal issue, yet
>another wonderful Redhat  problem (if that's the case), as I've had
>problems with signals and RH in the past, but I'm not sure.
>
>I've gone through, tried removing the signal stuff, it still does the
>same thing (crashes the mud), have tried a couple of various 
>things, and
>it's still doing it.
>
>I've enclosed the code I'm using (not something I wrote mind you, just
>modified it a li'l), in case someone can see something I'm 
>missing here.
>
>I've poured through logs, no core dump, nada. Thoughts, ideas?
>
>+----------------------------------------------------+
>+   TJW: Head Tech, designer: Dreamless Realms Mud   +
>+   Mud : http://drealms.kyndig.com                         +
>+   Telnet: drealms.kyndig.com port 9275                    +
>+   OLC Docs: http://olc.kyndig.com                       +
>+----------------------------------------------------+
>
>
>

Reply via email to