Version 4.35.0.14 : TMSLoader.OnPutData : Stack Overflow

Discussion of open issues, suggestions and bugs regarding SDAC (SQL Server Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
PaulT2
Posts: 29
Joined: Wed 15 Aug 2007 19:31

Version 4.35.0.14 : TMSLoader.OnPutData : Stack Overflow

Post by PaulT2 » Mon 02 Mar 2009 09:14

I have an issue on a customer site which unfortunately due to security restrictions we do not have access to. It's unfortunate as I now have a "Stack overflow" error reported in the server log (which I have seen), being generated in the "OnPutData" procedure. This code is running in a dozen or more sites and has been for a few years, so it is something peculiar to this particular customer.

I am continuing to ask questions of the onsite people, but I have run out of things that we have come across in the past. Any thoughts or directions you could provide would be appreciated... Some facts which may or may not be relevant:-

1). System is running on 32bit vista against SQL2005 SP2 developer edition database on the same machine (a laptop). This itself is perculiar for our system. The customer is still a "prospect" at this stage and so has not gone into production. We do not implement systems on Vista, they are implemented on server platforms.

2). I know the volume of data going through the OnPutData will be large (but most likely no larger than any other implementation we do). There are likely to be anything from 1,000,000 to 30,000,000 records being pumped through the load. This is normal for our system and works flawlessly, normally.

3). Our "server" application that contains the OnPutData uses a lot of memory. We always require the /3GB switch setting on servers. Although I have had the on site techie set the Vista equivalent (IncreaseUserVa ), I still suspect Vista in this. From a performance monitor trace, the "virtual bytes" count is stable at the failure point - at around 1.5GB, which is well within limits. The times we do have issues with memory, it is earlier in the process, when heap space is being consumed heavily. At the point of failure, we are just writing out records with no additional memory being asked for.

4). In the coding, the OnPutData does "nothing" special. It is basically just a few nested (but NOT recursive) loops that "report" large amounts of data back to the database. There are a few procedure and function calls within the "OnPutData", but nothing that is recursive.

Any thoughts greatly appreciated,

Paul.

Dimon
Devart Team
Posts: 2885
Joined: Mon 05 Mar 2007 16:32

Post by Dimon » Wed 04 Mar 2009 14:35

I could not reproduce the problem.
Please make sure that you do not use recursive call procedures and you have enough memory for stack buffer.

PaulT2
Posts: 29
Joined: Wed 15 Aug 2007 19:31

Re: Version 4.35.0.14 : TMSLoader.OnPutData : Stack Overflow

Post by PaulT2 » Wed 20 Jun 2012 08:13

This is just a note, possibly to myself in another 3 years time when I'm Googling the same issue again....

Yesterday we again saw an incidence of a stack overflow being triggered in the OnPutData of a TMSLoader. This time though we had access to the customers database and were able to debug the issue.

As it turns out, the problem has nothing to do with the TMSLoader component, but is ultimately a call to a TList.Sort and it's QuickSort implementation. The particular dataset going into the sort at that point would appear to be "degenerative" and cause extreme recursion of the algorithm.

We have yet to decide if a solution needs to worked out, but the problem is definately not DevArt related.

Paul.

AndreyZ

Re: Version 4.35.0.14 : TMSLoader.OnPutData : Stack Overflow

Post by AndreyZ » Wed 20 Jun 2012 11:01

It's good to see that you pinpointed the cause of the problem. If any other questions come up, please contact us.

Post Reply