I am supporting a legacy Cold Fusion system and I cannot understand why every now and then I get the following error:
Element ROOT.DSN is undefined in APPLICATION.
The error appears seemingly on random places and does not make sense to me. If I understand how cold fusion works - every request first processes Application.cfm, right?
There we have:
if (not isDefined('Application.Root'))
include '/lib/config/CreateRoot.cfm';
CreateRoot does some initialization and setting ROOT.DSN is one of them.
This doesn't make any sense to me, because usually the caller also loaded some stuff from database, so how come one function can "see" this and it's gone when we get into another? It's not ROOT.DSN but sometimes other settings, that we initialize the same way.
A retry is usually successful so the only explanation I can some up with is that the server is running some garbage collector and cleaning up some memory when this happens.
My questions are:
Why does that happen and why/when are Application variables lost?
How to prevent it?
using the correct scope it's an important factor to prevent these issues. Please use "application.root.ds" to make sure you are indeed calling the correct scope. The application variable will only reset if you do the following:
restart the application
rename the application
restart the machine, which inherently restarts the application as well on the server.
manually reset the application scope
other than that once the application runs for the first time you should always be able to access it and it should not restart.
Related
We currently have a series of variables that are loaded into the application scope that rarely change.
By rarely change, I mean that they are strings like phone numbers, or simple text values that appear on a website and may change once a week or once a month.
Since we are reading these variables and because they rarely change, is there any requirement to encapsulate these inside a cflock ?
I think it would be alot of coding overhead to wrap these variables inside a cflock as the template may contain upwards of 20 instances of these static variables.
Any advice on this greatly appreciated
Personally I would say you do not need to. These variables are essentially constants.
However, you need to assess this yourself. You need to answer the question, 'what would be the ramifications of these variables being read with stale data?'
This means, if as in your example the wrong phone number is used on a request is this a disaster? If that is a problem that you can live with then you can make no changes. If however there are variables that are used in calculations or ones that will cause unacceptable problems if they are stale, then you will need to lock access to these. In this way you can focus your efforts on where you need to and minimise the additional work.
As an aside if you do need to lock any variables then a good pattern to use is to store them inside a CFC instance that is stored in application scope. This way you can handle all the locking in the CFC and your calling code remains simple.
Depending on the version of ACF, Railo, etc... you are using I would suggest that data like this might be better stored in the cache and not in the application scope. The cache can have more persistences through restarts, etc... as well and could be a more efficient way to go.
Take a look at the cacheput, cacheget, cachedelete, etc... functions in the documentation. I believe this was functionality was added in CF9 and Railo 3.2.
Taking it one step further you could simply cache the entire output that uses them for X time as well, so that each time that part is loaded it only has to load one thing from the cache instead of the twenty or so times you mention.
If you are going to store them in the application scope then you only really need to have the cflock around the part of the code that updates them and lock it at the application level. That way anything wanting to read them will have to wait for it to finish updating them before it can read them anyway as the update thread will have a lock on the application scope.
This question already has answers here:
Watch a memory location/install 'data breakpoint' from code?
(5 answers)
Closed 9 years ago.
In Windows (both 32 and 64 bit), through program (C++) is it possible to determine if a certain memory location has changed? I am trying to extrapolate the concept that we see in Visual Studio where we can set data break point.
Use Case: I understand its a dirty hack, but the fastest to implement to be re-implemented later
I am sharing data across process boundary (read between a 32 bit client and 64 bit server). The Client allocates memory (beyond our control) and passes the address to the server. The Server allocates a storage to shadow the client memory and via various code path can update that shadowed memory location. Instead of identifying and trapping each of these location (I was trying to find an easier path), to raise an event on change and eventually write back the data through WriteProcessMemory to the client process
Whilst it's probably possible to find a solution using a combination of VirtualProtect and the Windows debug interface, I'm not sure it's a particularly good solution for this scenario. One of the problems is that you introduce a delay on every new write, and you are looking at a transfer to another process that is monitoring the program as a "debugger". That process will then have to "unprotect" that page, mark it as "updated" for the other Server (or Client, depending on which direction you are going), and "continue" the application making the update. This is quite time consuming. And of course, there is no trivial way to know when the writing process has completed a sequence of updates. You also need to know exactly where to "continue" when there is a SEH "__except" call, and it's not always entirely trivial do to that, especially if the code is in the middle of a memcpy or something like that.
When I worked with graphics, I know that both our and some competitors driver would do this, first write-protect the memory, and then by hooking into the windows own page-fault handler, look up the page-fault, see if it's the special region(s), and if so, mark that page as updated and reset it to writeable. This allowed the driver to only copy the updated regions. But in this case, there is a distinct "I want to draw this stuff" after all the updates have been made.
If you want to badly enough, you can use the debug API to set a breakpoint on your own data, which will be triggered on a write, just like the VS API does.
The basics of this are to start a thread to do the "debugging". It will:
temporarily stop the primary thread.
Get that thread's registers with GetThreadContext
set the address to break on in one of DR0 through DR 3.
Set the size of the data in question in DR 6.
Set the type of breakpoint (data write, in this case) in DR 7.
Use SetThreadContext to tell the primary thread to use the modified registers.
Restart execution of the primary thread.
That's going from memory, so although I believe it's pretty close to the basic idea, I may have gotten a detail or two wrong, or (more likely) left out a few steps.
In most cases, it's going to be easier to do something at the source level, where you overload operator= for the target in question, so you get some code executed during assignment to the data. Then in that operator you can (for example) set an Event that code in another thread waits on (and reacts appropriately).
Another possibility (especially if you want to break on any access to a whole range of addresses) is to use VirtualProtect to force an exception on any access to that block of memory. Like a debug exception, this will be triggered synchronously, so if you want asynchronous execution you'll have to accomplish it by setting an Event (or whatever) and having another thread waiting on that so it'll execute when the Event is set.
In a project, I'm talking to an object in a .EXE server (the object performs expensive queries for me which should be cached), and I seem to have gotten my reference counts wrong, which makes the server process free an object it still holds a reference to, making the host process fail in curious and interesting ways that involve losing data and sending a bug report to the vendor.
Is there a way I can ask COM to raise some condition that is detectable in a debugger if a proxy object whose refcount has dropped to zero is used in some way?
It's not likely that this is possible using raw interfaces - the reference count is maintained by the COM server and how it's impelmented is up to the server - the implementation is inside the server code, so unless you have the source and can debug the server, you have no way of getting to it.
However, it is likely your problem is cause by manually calling AddRef and Release. If that is the case, you can use a RAII/smart pointer solution. ATL provides one, but if for whatever reason you can't use that, it's easy enough to create your own. You can then not only create or use provided debugging facilities to keep track of reference counting, you will be much less likely to get it wrong in the first place.
When I try to run my program it never enters the main() function, but just hangs. Some how though, my program is throwing an exception in one of my classes as the first call in the stack after numerous calls to ntdll.dll. The exception seems to be the factor that is causing my program to hang with a "< bad ptr >". I am unable to trigger any breakpoints I set though, making it harder to find where the problem originates.
You need to figure out which system call you made that caused the crash. Normally this kind of thing is the result of passing garbage into some windows API.
Use a debugger and look at the call stack. The last entry that is inside your code is likely to be the cause of the problem. It probably has some bad data that is it not handling correctly.
This sounds like you are using global objects/singletons. If any of these depend on each other you are in trouble. I would look for all your globals and put a break point in the contructor of each. It sounds like the contructor for one global is using another global but the second has not been contructed yet.
Finally if this is not the cause, and your application is loading 3rd party dlls they might be clashing. I remember once orbix and ms message queue dlls classing in one was loaded before the other, everything worked if they were loaded the other way around. In the end to find this I removed every thing till I was just left with an empty main and then started adding things one by one until I found the problem.
I'm running into a perplexing problem with an ActiveX control I'm writing - sometimes, Internet Explorer appears to fail to properly unload the control on process shutdown. This results in the control instance's destructor not being called.
The control is written in C++, uses ATL and it's compiled using Visual Studio 2005. The control instance's destructor is always called when the user browses away from the page the control is embedded in - the problem only occurs when the browser is closed.
When I run IE under a debugger, I don't see anything unusual - the debugger doesn't catch any exceptions, access violations or assertion failures, but the problem is still there - I can set a breakpoint in the control's destructor and it's never hit when I close the broswer.
In addition, when I load a simple HTML page that embeds multiple instances of the control I don't see the problem. The problem only appears to happen when the control is instantiated from our web application, which inserts tags dynamically into the web page - of course, not knowing what causes this problem, I don't know whether this bit of information is relevant or not, but it does seem to indicate that this might be an IE problem, since it's data dependent.
When I run the simple test case under the debugger, I can set a breakpoint in the control's destructor and it's hit every time. I believe this rules out a problem with the control itself (say, an error that would prevent the destructor from ever being called, like an interface leak.)
I do most of my testing with IE 6, but I've seen the problem occur on IE 7, as well. I haven't tested IE 8.
My working hypothesis right now is that there's something in the dynamic HTML code that causes the browser to leak an interface on the ActiveX control. So far, I haven't been able to produce a good test case that reproduces this outside of the application, and the application is a bit too large to make a good test case.
I was hoping that someone might be able to provide insight into possible IE bugs that are known to cause this kind of behavior. The answer provided below, by the way, is too general - I'm looking for a specific set of circumstances that is known to cause this. Surely someone out there has seen this before.
To debug a problem in COM with C++ where an object's (C++) destructor is not being called, the best approach is to focus on how the COM object's refcounts are being incremented or decremented. What is probably happening is that somebody is incrementing the refcount one too many times, and then not decrementing it the same number of times. This leads to the object not being freed.
It is possible that your dynamic HTML is simply showing up a bug in IE, which doesn't happen if you use a static page.
If there is a bug in IE, the trick would be to figure out what causes the bug to appear, and what you can do to trick IE into releasing your COM object properly (like, making the HTML go away).
Another approach - add cleanup code to your DllMain function (adding that function if it doesn't already exist). Then regardless of reference counts (and reference count errors), when your DLL is unloaded you can clean yourself up:
BOOL WINAPI DllMain(HINSTANCE, DWORD dwReason, LPVOID) {
if (dwReason == DLL_PROCESS_DETACH) {
CleanUpAnyObjectsStillAlive();
}
}
Oh, and a word of warning - don't take too long doing your cleanup - if you do, I can't promise the process shutdown won't kill you anyway.
I have the same problem, but only on a specific computer.
This computer also has a problem with the Flash ActiveX, that remains alive after closing the tab.
My guess is that the problem is not with your code. Do you have that problem on other computers?