I have a TFDMoniFlatFileClientLink on a form, filename set to d:\temp\monitor.txt, tracing=true, TFDConnection.Params.MonitorBy=mbFlatFile. This sometimes works and sometimes does not trace anything. No file gets created.
Tested with Win7 32-bit app, with design time TFDConnection to either FireBird or Oracle. Delphi Tokyo 10.2.1
What is going on?
This was a really weird bug:
It turns out that the TFDMoniFlatFileClientLink remembers the filename when removed and placed back, then does not trace.
To reproduce:
Remove the TFDMoniFlatFileClientLink, optionally save the project, place a TFDMoniFlatFileClientLink on the form again, set tracing=true. It has magically remembered filename d:\temp\monitor.txt (where?), then either does not trace or traces to C:\Users\username\AppData\Local\Temp\traceX.txt.
Only when you change the filename does it successfully trace again.*
Similar weird things happen with TFDMoniRemoteFileClientLink, it very often does not create trace output for FDMonitor to pick up. I have not investigated the exact conditions under which this happens.
I found this in a test app after tracing the following issue, possibly related:**
A design time TFDConnection gets its parameters filled at run-time. I executed TFDConnection.Params.Add('MonitorBy=mbFlatFile') but the app did not trace. I verified that MonitorByInitial=true at run-time. Params.Add('MonitorBy=mbRemote') also failed.
A TFDMoniFlatFileClientLink and TFDMoniRemoteClientLink were placed on the datamodule at design time.
Reported in Embarcadero Quality Portal under issue RSP-19554
* Even if you change it to the same file name. If you do that at run-time you have to set Tracing=false/true around the FileName assignment.
** Mmm, not related. Reported as RSP-19559
Related
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
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 been having an issue with MVC 5.2.3 (and earlier versions back to about 4) using Razor (VB.NET) views where
1) I can't reliably set breakpoints inside a View (doesn't work most of the time even if VS doesn't give me a warning that it couldn't bind, which it often does)
2a) When it hits an exception within a View, the debugger often opens the wrong file (can inspect values fine though!)
2b) Examining the stack trace for the exception shows the wrong file!
3) Occasionally an exception thrown within a View doesn't resolve to any View file at all and the debugger just says it can't find the source and the stack trace doesn't show any file
I've had this on multiple computers running VS2013 and 2015 on Windows 7 and 10. I'm just using the default routes that were set up with the original project template. This has been going on for probably a couple of years now. I think it is affecting multiple projects, but I've mostly been concentrating on one recently so can't remember for sure.
Sample stack trace - note the "no relevant source lines" and the "OperationsMatrix.vbhtml" which is underlined - there is no reason that view should be included and it definitely isn't rendering if there is no exception! The correct view is "AnalyticsReport.vbhtml" (line 122) which is being partially rendered from within "SalesAnalytics.vbhtml" (at line 108). The debugger is also incorrectly opening "OperationsMatrix.vbhtml" on an irrelevant line (the only thing on that line is an End Sub for a lambda method).:
I've had a look in the temp file it is referencing in the stack trace and that seems to be just be referring to OperationsMatrix.vbhtml, so that file seems to be wrong too, but it doesn't actually seem to be executing that, because I can fix the bug in AnalyticsReport.vbhtml and the exception stops occurring.
After changing some code and changing it back again (ie. effectively the same code), it is now generating the following:
Note that there is now source code referenced at the top (from the wrong file - LiveStock.vbhtml) and that file is now appearing near the top of the stack trace instead of one not being found. Lower down, OperationsMatrix seems to have disappeared and it can't seem to find anything for that one. I am pretty sure that the top one should be AnalyticsReport and the lower one should be SalesAnalytics. I'm pretty sure that it should be mapping to Layout.vbhtml as well, which doesn't seem to be working in either of these tries (not noticed/can't remember if it ever does). It seems to be fairly consistent in terms of it either doesn't find anything or it finds another file in the same folder.
I've just had another look at the generated files in the temp folder for that second stack trace. App_Web_grga51wc.3.vb appears to be for a different file and App_Web_grga51wc.1.vb seems to be the one for _Layout.vb. The file refs in the #ExternalChecksum and #ExternalSource directives appear to be correct, so I don't think that the problem is in the code generation or mapping the code from the generated file back to the original using the #ExternalSource directives. The problem seems to be that it is mapping the IL compiled code back to the wrong generated source file (presumably a problem with the PDB file?). I have no idea how or why this is happening, or why it seems to only be affecting MVC projects and nothing else.
For absolute clarification, the views which are being returned are apparently random from the same folder and are not referenced in any way by the view with the bug causing the exception. They are generally not designed to be partial views and often it wouldn't make sense to use them as a partial view - they are usually full, unrelated views which are designed to be used completely independently of the one which is being called.
I've also tried deleting the whole temp folder that it is using and obviously clean and rebuild etc. Also tried disabling the VS profiling tools.
nb. there is no consistency with which view is incorrectly opening. A different one was being opened when I had a slightly different exception a few minutes earlier.
Any ideas?
Finally worked it out!
In the web.config file for the site (the root one, not the one in the Views folder) the \ had an attribute as follows: -
assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
I have removed this attribute and it seems to be debugging fine now! It looks like VS2013 added this when I initially created the project and it has been corrupting the DLLs/PDBs that are generated and messing up the debugging.
To clarify, if anyone else has the problem, the compilation opening tag now just looks like
<compilation debug="true" targetFramework="4.5">
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 have run into a situtation where frequently when debugging a ISAPI Dll (TWebModule) running under Apache I get errors. The caption on the error box is "Debugger Fault Notification" and contained in the message is, among other things:
"c:\program files\Apache\bin\httpd.exe faulted with message......."
When this happens the cpu window pops up, and I have to hit the "OK" button on the error message. I might have to do this 3 - 5 times before program flow continues.
This is happening on my laptop. I have a desktop with the same exact configuration (as far as I know) and I don't have this problem. Both operating systems are XP. So obviously there is some setting or outdated file somewhere.
Also, I have noticed if first run my website when Apache is not in the debugging envrironment it seems not to have this problem. (i.e. start apache in the services, run my web app, stop the service, and then debug it within the Delphi environment).
Any ideas???
While it doesn't directly answer the how to debug using Apache, another alternate debugging technique which works well is to use idDebugger (near the bottom of that page). It will allow you to debug ISAPI DLL's directly from the IDE without having to start/stop services. I now never develop ISAPI DLL's without it.
To avoid this and other problems, I've started xxm. It's an alternative to TWebModule, and uses a separate wrapper to run with IIS, but there's also an Apache, FireFox and IE wrapper! It also uses mixed-HTML-Delphi-source and the development-mode wrappers do the parsing and an auto-compile to give a web-script-like environment.
Also the InternetExplorer plugin works great in the debugger (with iexplore.exe as host application).
Error code 0xC0000008 is Status_Invalid_Handle. That can be thrown by CloseHandle, for example, when you try to close a handle that either was never open or was already closed. The error might not occur when you're running outside the debugger because the API won't throw an exception unless it's being debugged.
If you're getting that exception in code that the debugger doesn't have access to, then the debugger will display the CPU window instead. Look at the call stack to find the place in your code closest to where the exception came from.
It's also possible that it's not occurring in your code at all. Try doing your same debug routine without your module installed. Do you still get errors?