| View previous topic :: View next topic |
| Author |
Message |
Papillon
x-man
Joined: 28 Dec 2004
Posts: 1060
Location: Germany
|
 Posted: Fri Jan 21, 2005 18:27 Post subject: |
 |
|
| Senalaya wrote: | Are you sure, that it's the malloc() of nwnx_odbc that causes the trouble? Or could it be the memory allocation of the intergrated MySQL/SQLite libaries?
I havn't had any crashes with the ODBC part. |
It is no different with the ODBC connection:
| Code: |
AllocatePointer(columnSizePtr);
SQLGetData(hstmt, 1, SQL_C_BINARY, pReturn, columnSizePtr, &cbData);
|
The AllocatePointer() causes the troubles, apparently.
_________________
Papillon |
|
| Back to top |
|
 |
Makzimia De Graf
Joined: 31 Dec 2004
Posts: 55
Location: San Diego CA.
|
| Posted: Fri Jan 21, 2005 18:30 Post subject: |
|
|
What objects are we talking about here Pap? per player? per item? per transaction? just trying to clarify please.
_________________
Makzimia De Graf
DM/Creator Island of Fredian
fredian.game-host.org:5123
Forums at http://castille.us/fredian/Forums |
|
| Back to top |
|
|
Papillon
x-man
Joined: 28 Dec 2004
Posts: 1060
Location: Germany
|
| Posted: Fri Jan 21, 2005 18:44 Post subject: |
|
|
Per call to RetrieveCampaignObject.
Btw, I just tested the whole stuff with a ODBC connection: It is true that the call to RCO suceeds, but the server crashes upon exit - another sure sign of heap / stack corruption.
_________________
Papillon |
|
| Back to top |
|
|
Papillon
x-man
Joined: 28 Dec 2004
Posts: 1060
Location: Germany
|
| Posted: Fri Jan 21, 2005 18:47 Post subject: |
|
|
Now who's the geek to explain me what is going on here ?
_________________
Papillon |
|
| Back to top |
|
|
Makzimia De Graf
Joined: 31 Dec 2004
Posts: 55
Location: San Diego CA.
|
| Posted: Fri Jan 21, 2005 18:52 Post subject: |
|
|
*chuckles* Salandra walked off into the bedroom shaking her head at us. RCO calls in Fredian are none existant, if I am understanding what you are saying... so... total loss on this. Again, as it stand ODBC via layer driver is still standing now after 12 hours of no crashes... *throws hands in air* I am sorry Pap, something for you coders to mull over and tear apart.
_________________
Makzimia De Graf
DM/Creator Island of Fredian
fredian.game-host.org:5123
Forums at http://castille.us/fredian/Forums |
|
| Back to top |
|
|
Papillon
x-man
Joined: 28 Dec 2004
Posts: 1060
Location: Germany
|
| Posted: Fri Jan 21, 2005 18:57 Post subject: |
|
|
| Makzimia De Graf wrote: | | RCO calls in Fredian are none existant, if I am understanding what you are saying... |
Well, I am talking exclusively about RCO/SCO calls and the associated crashes here.
_________________
Papillon |
|
| Back to top |
|
|
Makzimia De Graf
Joined: 31 Dec 2004
Posts: 55
Location: San Diego CA.
|
| Posted: Fri Jan 21, 2005 19:01 Post subject: |
|
|
Ok, well when you sort this out, which I am sure you will, can we expect that this will impact the fact that it's effecting something else also, since I have none of this RCO SCO thing going on? sorry to have hijacked this thread.
_________________
Makzimia De Graf
DM/Creator Island of Fredian
fredian.game-host.org:5123
Forums at http://castille.us/fredian/Forums |
|
| Back to top |
|
|
Senalaya
Joined: 29 Dec 2004
Posts: 82
Location: Germany
|
| Posted: Fri Jan 21, 2005 19:07 Post subject: |
|
|
Could be silly me, but as far as I see in the original 0.92.2, you create a 'new BYTE[size]' on each RCO call, where does it get released again? Does NWN do the clean up with the original RCO?
db.h: | Code: | void AllocatePointer(int size)
{
if (size > returnSize)
{
if (pReturn)
delete[] pReturn;
pReturn = new BYTE[size];
returnSize = size;
}
} |
Last edited by Senalaya on Fri Jan 21, 2005 19:22; edited 2 times in total |
|
| Back to top |
|
|
Papillon
x-man
Joined: 28 Dec 2004
Posts: 1060
Location: Germany
|
| Posted: Fri Jan 21, 2005 19:18 Post subject: |
|
|
| Senalaya wrote: | | Could be silly me, but as far as I see in the original 0.92.2, you create a 'new BYTE[size]' on each RCO call, where does it get released again? Does NWN do the clean up with the original RCO? |
See, this is a very interesting question. I have not been able to prove the one nor the other, so this remains an open question! Welcome to the wonderful world of reversed engineered assembler code hooked via a DLL into some executable that right from the start did not want to have anything to do with database stuff 
_________________
Papillon |
|
| Back to top |
|
|
Papillon
x-man
Joined: 28 Dec 2004
Posts: 1060
Location: Germany
|
| Posted: Fri Jan 21, 2005 19:21 Post subject: |
|
|
One fact I know for sure is that the crashing did not go away when I do NOT release memory, but just malloc'ed more of it. This seems to point to the fact that NWServer does not want to free() it, but just does a memcopy() on it.
The questions remains why a simple call to malloc (or new) messes up the whole server. I have even tried to allocate 100KB of memory in the odbc constructor beforehand, resulting in the same problem.
Oh, and my ICQ is 169824305
_________________
Papillon |
|
| Back to top |
|
|
crusaderky
Joined: 13 Jan 2005
Posts: 2
|
| Posted: Fri Jan 21, 2005 19:23 Post subject: |
|
|
| Senalaya wrote: | | Could be silly me, but as far as I see in the original 0.92.2, you create a 'new BYTE[size]' on each RCO call, where does it get released again? Does NWN do the clean up with the original RCO? |
a good code profiler IMHO should be able to detect any eventual memory leaks of this type.....
....I repeat, IMHO. Most likely I'm talking without knowing things.
_________________
I Sette Sigilli - Shard Italiano Full GdR |
|
| Back to top |
|
|
Senalaya
Joined: 29 Dec 2004
Posts: 82
Location: Germany
|
| Posted: Fri Jan 21, 2005 19:28 Post subject: |
|
|
Hmm, the blockwise transfer of SQL blobs from and into columns usually takes some time. I asume (too lazy to read), that nwnx_odbc uses only one instance of the CDB/CODBC object, to handle all RCO calls.
Would it be possible, that if 2 RCOs are fired shortly after eachother, that the 2nd call destroys ('delete[] pReturn;') the pReturn pointer, while the 1st call is still working with it? |
|
| Back to top |
|
|
Papillon
x-man
Joined: 28 Dec 2004
Posts: 1060
Location: Germany
|
| Posted: Fri Jan 21, 2005 19:32 Post subject: |
|
|
No, it is single threaded.
_________________
Papillon |
|
| Back to top |
|
|
Senalaya
Joined: 29 Dec 2004
Posts: 82
Location: Germany
|
| Posted: Fri Jan 21, 2005 19:37 Post subject: |
|
|
| ignore! Missed the point, that it also crashed, when no 'delete' is used. |
|
| Back to top |
|
|
Earandel
Joined: 29 Dec 2004
Posts: 6
|
| Posted: Sat Jan 22, 2005 5:32 Post subject: |
|
|
Pap,
I actually ran into something very similar when I was working on extending the SCO module. I tracked it down to the same AllocatePointer type call ( a new one I added in the code I sent you ages ago). It seemed to me that NWServer did not overly like the pointer to be reused. I tried removing the size check - taking the performance hit of deleting and re-allocating the pointer each time, regardless of the size. This will be slower, but it seemed to be significantly more stable.
Ear |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
