I have a cocoa app which uses core data. Everything seems to be working fine.
However, in a very specific scenario the app was behaving very strangely for our client.
In particular the logs shows this appearing in the output many times (which I've never seen in my testing):
Core Data: annotation: -executeRequest: encountered exception = Updating max pk failed: with userInfo = {
NSSQLiteErrorDomain = 14;
}
Has anyone ever seen this message and do you know what it means? I've tried googling it but found no information other than a few message boards regarding the Growl app having similar problems, with no solution yet available.
Sorry that I can't be more specific regarding what causes this as I'm not even sure myself. I know how to reproduce this on the client's machine but this message seems very random.
I was hoping someone could give me some more information as to what this error means exactly so that I can maybe narrow it down some more. Right now I'm pretty clueless.
Note: This appears on a macbook pro running 10.7.2 (if that matters).
Thanks for any kind of help you can provide, even something vague would help me at this point.
Update:
The managed context "save" method also fails with the following error:
The operation couldn’t be completed. (Cocoa error 134030.)
This is not really a Core Data problem as such, but more an issue of you process running out of file descriptors.
Each process has a limited number of file descriptors. If you run out, Core Data (and many other things) will stop working, because they can no longer open files -- any they'll fail.
First of all, make sure you're not leaking file descriptors, i.e. make sure you close files when you no longer need them.
I'm not sure what kind of changes you're trying to track. Take a look at Tracking File-System Changes.
If you're on 10.7, take a look at dispatch sources and DISPATCH_SOURCE_TYPE_VNODE for a very powerful tool to track file system changes (corresponds to kqueue, but is easier to use).
Core Data also gives this error in a Sandboxed app when it tries to save DB to a location where it doesn't have full read/write access to (if a user opens file for example, Core Data will be able to read/write this file, but not anything else to the same folder).
Core Data fails to write the temporary _journal file to this folder and reports this error.
Related
When I try to load a form in the designer, it shows "runtime error 0" and produces a log file which contains:
Line 15: Cannot load control xxxx; license not found.
But the control in question DOES NOT have any licensing restrictions. It has no installer and requires only registration (regsvr32).
Not only that, but for years this had worked without any problems and only just recently this has started. It affects a number of forms which have any controls from a particular OCX.
So it appears that something is fooling VB6 into either thinking a license check has failed, or at least to show a nonsensical error message.
I have tried to trace this using Process Monitor but I couldn't spot any useful clues in the logs. At least, nothing which was obviously problematic.
Any ideas what could cause this? I'm at a loss so far to find a cause.
Thanks
I'm assuming this is a third-party OCX... Many such products came with their own installer which generates the license file; simply copying, and even regsvr32ing the .ocx is not sufficient to use it in the development environment. If you still have the original installation routine, you can try running that to regenerate the license. Failing that, you could look for an appropriately-named .lic file on an existing, working development machine (in \Windows\System32, or the VB6 installation directory, or in the directory into which the .ocx is installed) and manually copy that to the same place on the new development machine.
(Answering my own question, should anyone else run into this again).
As far as I can determine this error was caused by either a subtly corrupt FRX file and/or an FRM/FRX file pair being out of sync.
By going back in source control I could eventually locate a revision where there was no problem. This alone seemed to eliminate anything in the computing environment from being the cause. (ie, bad VB6 installation, disk space, etc. etc.)
I manually re-did certain changes and brought that older code back up to date, and so far the problem has not reappeared.
EDIT the struck-out text was not incorrect but was not specific enough -- I have since learned what seems to be the root cause.
The problem was that we loaded a 32-bit ICO file (icon) into an imagelist in one of the VB6 forms. Now, traditionally 32-bit color icons were not usable in VB6 and you would get an error even trying to do this. However for some reason certain Windows PCs will now allow this - which can be a time bomb.
The problem is: forms saved that way can cause the errors in this question when run on a different PC which does NOT support such icons.
This will occur in the IDE when the form is loaded, OR if a compiled EXE is run on a different computer which respects the original VB6 icon limitations!
I don't know why the totally meaningless "licensing" error message is shown when this happens.
In my case we didn't intentionally introduce this icon, it was a mistake, and so it took a LONG time to debug and eventually figure this out (plus some very valuable advice from people on VBForums).
I've created a different question specifically to try and get at what underlying element of Windows has changed causing this problem.
I have the following scenario:
WPF Application using SQLite-file per System.Data.SQLite on a windows-share as backend. Client is Windows 7 Home Edition
A user reported, that she was using the software, saving the new data she entered, but then after a while when she re-visited the software, some of her stuff was gone.
She said the session lasted until about 11:50am - the timestamp on the SQLite file in question was 10:55am. I have a logfile in the same network share, it is written to using a filewriter with autoflush.
The logfile looks normal until 10:55am, then there is one line with rubbish (looks like several lines written together in one), then goes on as normal.
Clearly the network (or maybe the drive) must have had a hiccup at that time. Miraculously my application just continued as normal. No exceptions were thrown, according to the logfile all transactions are "completed". No journal file remains to tell the tale. This behaviour - although wonderous in itself - is not appreciated by the user :)
My question: what happened here and how can I prevent it in the future? Did Windows 7 cache the file in the standby list and not care at all about comitting the changes to the actual disk? Why is my application or the SQLite provider unaware of this?
I will now build a confirmation mechanism that checks the timestamp on the backend file to see if it was actually changed at all after the last transaction, but that seems a bit silly. Just as silly as being very pedantic with catching exceptions when they are not being thrown :)
Thank you
TL;DR
SQlite file shows no changes after momentarily hardware (network or drive) failure, but the application seemingly continues to function and no exceptions are thrown by System.Data.SQLite.
See section 3 of How To Corrupt An SQLite Database File; it appears that Windows did not sync the network share when SQLite told it to.
I have a VB6 application that I provide support for. This application works on both Windows XP and Windows 7. Some users were migrated from Windows XP to Windows 7 using the User State Migration tool. These users now receive a generic "Application has crashed" Windows error message when they open certain screens (forms) in the application. My assumption is that there is a missing dll/ocx reference, but I'm having trouble tracking it down.
I've tried many/varied troubleshooting techniques:
Full uninstall and reinstall of my application
Manually re-registering all dll's and ocx's that I know are used
Running Process Monitor on a broken computer and a working computer to compare what dll's and ocx's are accessed. The answer might be here but even after filtering out most of the background noise the amount of data is overwhelming. At a minimum I reviewed all of the calls right before it crashes and all of the calls that were not successful. All of the non-successful calls match between working and non-working.
Installed the Windows Debugger Tools and captured a crash dump. Analyzed the crash dump with DebugDiag. DebugDiag says the exception is in msvbvm60.dll. I tried building a PDB file for my exe and loading it in DebugDiag to get more detail about where the exception is occuring but DebugDiag doesn't want to accept the PDB (might be doing something wrong here, but it just seems to ignore it. This same PDB file works fine when I do remote debugging, however.)
I recompiled my VB6 program without any optimizations in PCode. I've read online that sometimes building in PCode, while bad for performance, will tell you the real exception.
Used the above created PDB file to remote debug the VB6 application. The debugger says that the application crashes after the new window has been created, on a line that sets MousePointer = vbHourGlass... To me it seems unlikely that this is the real cause of the error. There are at least 20 other locations in the program where this same line is called and all work fine.
(Forgot about this one)
Used Dependency Walker and profiled the application on both a working and non-working computer. All errors found by dependency walker were the same between the two computers. There were no additional dependencies found on a working computer, and all missing dependencies on the non-working computer were also missing on the working one.
None of these actions changed my error message or showed me what the error is (unless it really is the mouse cursor issue)... There are no entries in the Windows Event Log related to the app crash.
The non-working and working computers all have the same base Windows 7 image, the only difference is whatever is being changed by USMT, which further convinces me that this is some kind of quirky configuration change or a missing dll/ocx or perhaps an unregistered dll/ocx.
Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.
Update 1 - Response to questions
#MarkHall I have tried running it as admin, though not with UAC off. The application runs fine on a Windows 7 box as a non-admin with full UAC. Windows XP was 32-bit, Windows 7 is 64-bit, but again it works just fine on a like for like box where the user was not migrated from Windows XP.
#Beaner It's possible that it stores settings somewhere that have been corrupted, but the remote debugging leads me to think that it's more likely something else since it seems to die on a step related to the UI, which then makes me think it's probably a missing dll/ocx reference.
#Bob77 The application is installed into Program Files (x86). While many of the libraries do reside in the same folder, they are all registered.
Peter, often I've noticed that the debugger will indicate a line of code that is actually incorrect, depending on WHERE in the actual assembly language the fault occurs. You should look REAL close around your statement that sets the cursor to vbHourGlass. Your exception is PROBABLY happening BEFORE that line of code, but that line is what the debugger thinks is the actual faulted line of code.
Since you said it happens when a window OPENS, I'd look real close at any ocx's you may have referenced on the form, but perhaps NOT actually being used, or called. You might have one there that you don't intend to be there, that could be causing security issues, or something on Win7? Edit the .frm file by hand if you have to, and look at all the GUIDs the form references.
It is possible that one machine is using PER-USER registration, and the other is using PER-SYSTEM registration?? I don't know...
I would take a much closer look at the form that you are trying to open, and be VERY cautious of everything you are doing in the form load events, and so on. This sounds like it could be something as stupid as Windows Aero being enabled on one system, and not another, or some other sort of "Theme" setting that is throwing the VB Form Rendering routine into a hissyfit... Perhaps even something as stupid as a transparent color index in the icon you selected for that from?
If you are still developing this app, (or at least maintaining it), create an entirely NEW form, and re-create all the controls, etc, on the form (resist the temptation to copy/paste them from the old one...), and then see if THAT does the trick. Then, copy all the event code to the new form one event at a time, with at LEAST enough event code to make the form function, even if it's just a "dead form", that loads no data, or whatever the form is supposed to do. Check and debug after each change, and you WILL find it eventually. Of course, make sure you isolate one of the defunct systems to have a platform that you can duplicate the issue on, or then it's just guessing. I find that using something like Acronis w/ Universal Restore is a great option to then take the image file into a good HV, like VirtualBox, and then restore that image as a VM, so you can debug without interfering with your actual users. This sounds like a lot of work, but then again, so is re-writing an application that already exists, right? :)
Failing THAT... /* and */ are your friends!! (Well, we're dealing with VB, so ' would be your best friend! heh... But I'd start commenting out all the code on the form until that sucker opens. Then once it opens, start putting one line back at a time, and re-running it... That's called "VooDoo Debugging", but sometimes, you gotta do what you gotta do...
THANKS A LOT PETER! :) Now you got ME so involved in this, I feel like I'M the one debugging this sucker! Like if it was MY code I was trying to fix! :)
Let me know if any of this helps... I am actually quite interested in what you discover.
We've been plagued for several years by occasional reports from customers about a non-descript error message "Cannot set allocations" that appears on startup of our app. We have never been able to reproduce the problem in our own test environments so far. I have now run out of ideas for attempting to track this down. Here's a collection of observations that have accumulated over time:
Error message text reads "Cannot set allocations" (note absence of punctuation).
The window title simply reads "Error" (or the localized equivalent).
The "Cannot set allocations" text is always in English regardless of OS locale.
I have so far not been able to locate the DLL or EXE containing the message text.
Google is chock full of reports of this error for a variety of different products - but no solutions.
The only unifying aspect between the affected products I could make out so far was that they all appear to come in the form of DLLs that load into third-party processes (such as addins for Visual Studio or Windows Explorer shell extensions).
Our app is actually a shareware COM-addin for MS Outlook, written in Delphi (i.e. native code - no .NET).
The prime suspect in our case is the third-party licensing wrapper that we're using which decrypts and uncompresses our DLL into memory on the fly. Obviously I couldn't simply give an unprotected version of our app to the affected customers to verify this suspicion. Maybe the other vendors that this has been reported against are using similar products.
Debug versions of the protection wrapper supplied to us by the licensing vendor yielded no results: The log files looked exactly the same as from sessions where the error did not occur. Apparently the "inner" DLL gets decrypted and uncompressed all right but for some reason still fails to get loaded by the host process.
By creating an unprotected "loader" DLL we have been able to pinpoint the occurrence of the error somewhere behind the LoadLibrary call that is supposed to load our DLL into memory.
Extensive logging and global exception hooks in our own code (both the unprotected loader and the protected "core"-DLL) yielded no results at all. The error is obviously raised somewhere else.
The problem described in this earlier question of mine was very probably prompted by the same issue. This was before we created the unprotected loader stub.
The error only occurs at about 1-2% of our customers - whereas typically all installations at any affected customer's site are affected the same.
Sometimes the error goes away after we release a new version but often it will come back again after a couple of weeks or months.
Once the error has started to occur on a machine it does so consistently.
The error never occurs while connected to the affected machine via remote access (e.g. VNC, RDP, TeamViewer, etc.) and none of the affected customers are within travel distance from us so all we have to go by is log files and "eye-witness reports".
One customer reported that the error message dialog apparently was non-modal, i.e. he was able to simply move the dialog box to the side and continue working with the application (minus the functionality that our DLL would have provided). Not sure whether this is universally true in all other occurrences, too.
In some cases customers have been able to permanently rid themselves of the error by disabling or uninstalling other addins from other vendors that were sharing the host application with our own product.
The error has so far been observed on Windows XP, Vista and 7.
During the last few weeks we had a surge of reports from Outlook 2003 / Windows 7 users. Could the situation have been made worse by a recent Windows/Office-update?
Does anyone have any experience with this error at all?
Or any more ideas for investigating this?
I have only recently had this happen, which prompted my search and I ended up here. I can tell you that with me for sure it is in windows 7 home premium BUT ONLY WITH IE9 (which I hate by the way) it reduces the user back to the dummy stage and assumes that we have to be repeated flagged about everything.It will keep asking you if you want to disable add ons to speed up load times but usually on things that aren't really the things slowing the browser down in the first place,it is there is too much garbage loading in the first place.But back to the "Cannot set allocations", I for one have never expirianced it in any other browser which is not to say it doesn't happen with them.
This is going to be pure guess-work, but it sounds like maybe your third-party licensing software is trying to load your DLL at a particular location in memory, which - on these failing systems - happens to already be occupied by something else, perhaps a global hook DLL.
If you have a customer who is willing to work with you a bit, it might shed some light on the situation to get a crash dump (e.g., with ADPlus or maybe simpler with Sysinternals' ProcDump) when the error message is showing. That would show what modules are loaded and possibly the callstack (if it is from a message box at the time of the error as opposed to one that is catching an exception after the problem).
I also have experienced the "Cannot set allocations" issue. Royal pain. I had disabled Java, since I did not seem to need it, I used add/remove programs to remove Java from my system. Then I stated to get those errors. I have reinstalled, but disabled Java in IE explorer. Now I do not get the error anymore. Not a programmer, don't know why this happened. Maybe a clue for someone.
Win 7 - 64bit OS IE Explorer 10. Hope this helps someone figure this out. John
I've seen this happen. In my case a global hook dll created a large memory file mapping, perhaps to the memory the licensing dll was counting on.
I see "Cannot set Allocations" when I open google chrome only. Also after that, chrome closes with a msg saying "Whoa chrome has crashed..."
Still no solution :(
Also not a programmer, but it always happens when I open Chrome. It opens second window with error message 'cannot set allocation'. I usually close it and go on my way. if i don't it usually causes a crash. doesnt happen on any other browsers.
We have an exe file delivered by an ASP.NET application. This binary is actually modified on the fly in memory. Is there any way to sign the modified exe with authenticode in memory without writing to disk? There's probably no way to sign the original exe and still keep the signature valid after modification. We thought about using ram disk to help on disk i/o if we have to, but just wondering if there are any other options.
The problem is really how to get rid of the unknown publisher warning. So if there is any other way that does not involve signing or changing policy settings on the client's computer, please let me know as well.
I don't know the answer to this offhand, but I've seen it done by Just Great Software. They make customized installers for RegexBuddy and every time I've downloaded mine it's got its signature.
I'm curious though - why don't you want to persist the file to disk? You don't need to leave it there - persist it, sign it, load it back into memory and delete it. Or, persist it, and have an agent or cron job delete it after a couple days.