I'm using Delphi 10.4.1 Enterprise and wrote a VCL program using an SQLite database.
As I suspect a OneDrive issue, I mention that the source code folder is part of the zone managed by OneDrive.
At times, whilst debugging, my Delphi program hangs for unknown reasons, and Delphi quits without further notice. Whenever this happens, the connections between the MainForm and the DataModule (DM1) are lost: in the Object Inspector of the MainForm, all DataSource assignments, ie connections to DataSources in the DataModule, are gone. Moreover, when I reload the program, there is the error message
Access violation at address 500C3553 in module 'rtl270.bpl'. Read of address 00000008
Code-checking gives no errors, but when compiling the following message/request appears:
Module 'MainForm' links to module 'DM1' which cannot be found in the current project. Do you wish to remove/redirect the links to another module?
The weird thing is that the DataModule design form in the IDE can no longer be made visible, only its code remains. Therewith, from within the MainForm the DataModule neither is visible, since dropdowns in the DataSource connectors of the DB-controls remain empty. Last, but not least, when I try to save the MainForm, it says:
Module "*MainForm" references another module and cannot be saved until DM1 is loaded
Whatever I tried to get it back to normal, it was unsuccessful.
However, in the OneDrive root folder, I see a file named ".849C9593-D756-4E56-8D6E-..etc..", which seems to be associated with my program, because of its file date. It can only be deleted or modified when I close OneDrive, but it revives after restart.
I am stuck, for many days already.
Does anyone have an idea what is going on, and can give me a hint on how to proceed?
I found out what has caused the Access Violation that showed up after I tried to bring the datasource connections back in place. I did that by editing the DFM-file of the Mainform, rather than direct in the Object Inspector.
I normally do editing in dfm-files, but adding lines with datasource assignments appears not to be allowed. This was quite a tough lesson for me!
I am happy to have the program running again. Thank you all for your time, #Remy in particular.
Thanks,
JGMS
Related
It often happens, to me, that after testing and making a build while I forget to check the activate property first. Then when I install the program on a different system an exception occurs due to failed connection. It's really annoying.
I've searched for a solution for a long time but it looks like it is impossible without making a new connection component inherited from TFDConnection. I don't want to do that and maybe someone here knows a simple way to get around this problem.
Check out the property ConnectedStoredUsage in TFDConnection.
That controls how to use the Connected property value saved to the DFM.
So for your need, you can uncheck auRunTime.
For more info on ConnectedStoredUsage, see the DocWiki.
We have a complex Delphi application with a main exe and several dlls.
In main form (contained in application exe) we have menubar.
On selecting a menu the corresponding dll is loaded and a form conatained in the dll is shown modal.
The scenario is as follows:
Press F1 and the context help for the modal form is open.
Close the modal form (without closing the context help).
in the source code we have:
result := FreeLibrary(MH);
And the whole application crashes with the following windows error:
ERROR_ALLOCATE_BUCKET
602 (0x25A)
The bucket array must be grown. Retry transaction after doing so.
If we first close the context help and then close the modal form everything is ok.
The strangest thing is that we have 3 dlls crashing and 3 not crashing.
The flow goes thru the same code.
There is nothing in the Windows Event Log.
I thought as a workaround I could force close the context help on closing the modal form before unloading the dll but I cannot find pid or some task identifier which I could kill.
There is no child processes of the application pid.
In Task Manager 'Processes' tab I see the name of our application and the name of chm-file (without .chm) like a subtask (at least seems like so) and I can right-click 'Stop task' but programatically I cannot find this...
P.S:
We use .chm file and do not have HtmlHelpViewer in uses of any module.
We have associated specific help topic to controls in forms so they automatically display the corresponding help topic when the user focuses it and presses F1. So in fact we do not use Application.HelpCommand(.....) to show the help
**** edited ****
Currently we use Delphi Tokyo. The product is stared 15 years ago in Delphi7. It has several dll-s (some of them are extra product modules) with plenty of forms and frames.
**** edited ****
**LU RD's answer solved my problem:**
Application.HelpCommand(HELP_QUIT, 0);
P.S:
I cannot mark the answer as accepted. I do not know why.
"I thought as a workaround I could force close the context help on closing the modal form before unloading the dll but I cannot find pid or some task identifier which I could kill. There is no child processes of the application pid".
In order to close the context help, add this line in the modal form OnClose() event:
Application.HelpCommand(HELP_QUIT, 0);
Application.HelpCommand: Provides access to any of the Help commands in the application programming interface (API) of native Help handling functions HTMLHelp, WinHelp, or other.
See Vcl.Forms.TApplication.HelpCommand for further details.
Found this this post ISAPI web application hanging if FastReport.PrepareReport is called
It helped solving my problem partially. As well I´ve turned Wisiyng property to False on frxRichView. Since I'm retunrnig a base 64 string I've also tryed switched loading from StrToStream/LoadFromStream to LoadFromFile. The problem persist with multiple acess, 2 out of 10 process can finish loading my Pdf file. All the others requests hangs until timeout. Does anyone have an idea what else can I do? is there anyother way to retunr rtf format into Fastreport report Thanks.
I could only get time-out error using Selenium to test multiples request from the client side.
Update: I've figured that just having a TfrxRichView component in the report causes the hanging, it doesn't even need to have a rtf text on it. Replacing it to a memo all request are answered.
UPDATE: Got a answer from fast report and I wold like your opinion.
ok,
I had similar problems, and it is not easy to find out the reason, but maybe you can find your solution in between my considerations..
1) Stack Size
When ran in IIS your ISAPI is only a DLL called by a process, you are not the main process so you have to pay attention to stack dimension.
Normally a Delphi application have a default stack size of 1Mb, in ISAPI DLL you will have only 256Kb of stack.
Maybe you are facing a stack overflow exception.. it can explain why it does not occurr always but only in some circumstances..
2) Trapped Exception
In general you get some error during the preparation of report (aka all the job of working with data, expressions, variables, formulas etc etc..) can bring to a trapped exception. You may be unable to see it from outside but code execution was broken somwhere and report preparation had not finished.
3) MessageBoxes and/or standard Exceptions
when running in ISAPI you should not output anything to user interface,
maybe a message dialog (or an exception) can bring to unexpected behaviour.
4) Global Var
You should avoid global var because in ISAPI they will be common across threads
So, if you have sources, debug the application.. at first exception you should understand where is your problem..
If you have not sources.. chek the above list.. I hope you can find some useful information.
You have two ways to solve this:
1- Try to recreate this behavior while debugging your ISAPI DLL. If you are lucky, you can identify the thread that is hanging your application. Sometimes this is hard or even impossible to recreate.
2- If you have access to the hung ISAPI application instance, use a tool like SysInternals Process Explorer to create a minidump file. Your application must be built using full debug symbols and you should have the corresponding map file. With one (or more - even better) dump files obtained from your hung application plus the map file, you can use another tool, WinDbg to analyze it and find the cause. (Sometimes) WinDbg can show exactly which thread is hanging the whole application and the line of code that causes it.
If you have never done that, I must warn you that this kind of analysis is almost a gamble... You have to use several different tools with little
or no documentation, read heaps of technical info in various places. In the end, sometimes it works wonderfully and sometimes it fails miserably.
Because debugging ISAPI is not obvious, but also because I wanted to be able to switch easily between more different hosting solutions — and wanted to update my website on the fly without a restart of the web-server/service — I created xxm. It has a singular interface to the HTTP context, your DLL gets loaded by either a IIS ISAPI handler, or a HTTP.SYS handler, or an Apache httpd module, or for debugging locally you can just set xxmHttp.exe as host application to get IIS out of the way.
I've not found any other resources on this issue, so I figured I would ask the SO community. :)
I currently have an issue with my CFB2 client going into a memory leak about three seconds after I edit a particular file on one of our company webservers. This also occurs when I try and edit a local copy of the file. The leak is slow and would take many many hours to hold up all of my free RAM (~6.5GB/8GB physical). There is also a high CPU usage on the leak (anywhere from 25-45% | 1.8 GHz four-core). The only visual feedback I receive is in the Outline pane, where it extends infinitely into a loop of cfelseif tags. The pane also holds the loop before editing, but does not attempt to extend it.
This error first occurred whilst I was creating a cffile tag and because I could not close it, the conditional statements were mis-highlighted. I believe this is the root cause of the issue, however, I do not know why this occurred.
As I complete typing of this, I will move the file to a simple editor, remove the line that caused the error, and attempt to add it again, however I fear that the addition of the line will end in the same manner.
EDIT: I moved the page source into Notepad and removed the pesky cffile line. Then, I proceeded to delete the file from the webserver, create a new file of the same name, and add the code back. I closed the tag before adding any attributes just to ensure the same issue would not occur, and it did not experience the same loop.
I'm running into a very weird problem with a large application. I make heavy use of TObjectList storing a custom object on them. On large lists im experiencing weird crashes with "Access violation at address.. read of address.. " "privileged instruction" and others, when I use the CLEAR method. I've tracked this to happen exactly when attempting to delete the last item in the list. I've checked this by logging the contained objects deletion from their destroy proc, and also trying to deleting them on my own (for a := olist.count-1 downto 0 do.. debugmsg('deleting '+inttostr(a)).. olist.delete(a) ), both ways I get the access violation right when deleting the LAST remaining item in the list.
This doesnt happen always, cause I use clear in other areas, and also a few different (smaller) lists, but at a very specific point in my app this happens.
I've no clue what might be wrong, there's nothing trying to access the list during the clear, and the cointained objects do not have access to their parent objectlist, there has to be something screwing up in the TObjectList.delete/clear methods when it comes to clearing the last item.
Any suggestions? Using Delphi XE.
That sounds to me like you're freeing objects that have already been freed. To track this down, download the full version of FastMM, add FullDebugMode to the Conditional Defines line under Project Options->Delphi Compiler and the Map File option under Linking set to Detailed, and rebuild. (Build, not Compile.) Then copy the FullDebugMode DLL to the same folder as your EXE and run it. It'll watch your memory as you allocate and free and when you try to free the same object for a second time, it'll catch that and give you some very detailed debug data as to where the problem is coming from.
Are you sure the last object is valid and not already deleted? It could be in the list twice e.g. due to other bugs.