Corrupted project? fatal problem

I am trying to open my project, and I receive the error " This application has encountered a fatal problem and must be shut down."

Then, while reporting the error:

Exception: Unhandled OutOfBoundsException in RuntimeLockUnlockArrays

OS: macOS 13.4.1 (22F82)

IDE Version : 2023 Release 1.1

Stack Trace:
* RuntimeRaiseException
* RaiseOutOfBoundsException
* RuntimeLockUnlockArrays
* RBXojoWebView.ReconstructViewFromPlainText$b$o<RBXojoWebView>o<PlainTextContext>s
* RBXojoWebContainerControl.ReadDataFromPlainText$b$o<RBXojoWebContainerControl>o<PlainTextContext>o<FolderItem>
* RBProject.ReadDataFromPlainText$A1s$o<RBProject>o<PlainTextContext>o<TextInputStream>o<ProgressIndicator>
* Document.LoadFromFile$b$o<Document>o<FolderItem>bo<ProgressIndicator>bs
* IDEApp.OpenDocument$$o<IDEApp>o<FolderItem>bbbs
* IDEApp.OpenDocument$$o<IDEApp>o<FolderItem>
* IDEAppOpen$$o<IDEApp>
* _Z29CocoaFinishApplicationStartupv
* _Z27PluginGetCocoaViewCallbacksv
* __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__
* ___CFXRegistrationPost_block_invoke
* _CFXRegistrationPost
* _CFXNotificationPost
* -[NSNotificationCenter postNotificationName:object:userInfo:]
* -[NSApplication _postDidFinishNotification]
* -[NSApplication _sendFinishLaunchingNotification]
* _DPSNextEvent
* -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
* _Z29CocoaFinishApplicationStartupv
* _Z29CocoaFinishApplicationStartupv
* Application._CallFunctionWithExceptionHandling$$o<Application>p
* _Z33CallFunctionWithExceptionHandlingPFvvE
* _Z29CocoaFinishApplicationStartupv
* -[NSApplication run]
* RuntimeRun
* REALbasic._RuntimeRun
* _Main
* main

I have the project saved in a dropbox folder with history activated, so I should recover old files. But I tried a few earlier project files and I still have the problem.
Last days I worked hard on this project, and saved many times.
I already tried to open with Arbed, but I receive a similar error:

Internal Error (failed assertion)
[Questionário de Lipedema d.xojo_project] Unknown project type: Web2
A text file with the crash details has been created on your desktop. You may send the file to the developer of this program.

You have the following choices now:

• Ignore — ignore this error and continue using the application.

• Quit — quit this application. Upon relaunch, you will be given the option to reset all custom settings to see if that avoids the error in the future.


Arbed v1.9.6
Platform: OS X
Assertion error ([Questionário de Lipedema d.xojo_project] Unknown project type: Web2)

Stack trace:
RuntimeRaiseException
Exceptions.StackTrace%A1s%b
Exceptions.Assert%%bss
RB_VCP_Config.RB_Error%%s
RBBaseItem.RB_Error%%o<RBBaseItem>s
RBProject.ReadVCPProject%b%o<RBProject>o<RBVCPContext>o<TextInputStream>o<FolderItem>bo<ProgressIndicator>
RBDocument.LoadProjectFromFile%b%o<RBDocument>o<FolderItem>bo<ProgressIndicator>b
RBPrjVCPFileReader.OpenProjectFile%b%o<RBPrjVCPFileReader>o<ProjectFile>o<ProgressIndicator>o<RBPrjOpenOptions>&s
RBPrjFileReader.OpenProjectFile%b%o<RBPrjFileReader>o<ProjectFile>o<ProgressIndicator>o<RBPrjOpenOptions>&s
RBPrjSupport.LoadNewPrjItemsTree%b%o<ProjectFile>&o<RBPrjItemsTree>&so<ProgressIndicator>bbb
RBPrjSupport.LoadNewPrjItemsTreeShowingProgressAndErrors%b%o<ProjectFile>o<ProgressIndicator>&o<RBPrjItemsTree>bbb
HL.GetTree%o<HL.AProject>%o<FolderItem>o<ProgressIndicator>bb
RBPrjHLWin.RBPrjHLWin.!ShowProject%o<RBPrjHLWin.RBPrjHLWin>%o<FolderItem>
MainWin.MainWin.handleEditorDrop%%o<MainWin.MainWin>v
MainWin.MainWin.hlEditorBox_DropObject%%o<MainWin.MainWin>o<GroupBoxDroppable>o<MyDragItem>
Delegate.IM_Invoke%%o<GroupBoxDroppable>o<MyDragItem>
AddHandler.Stub.18%%o<MyDragItem>
GroupBoxDroppable.TimerFired%%o<GroupBoxDroppable>o<Timer>
XojoFramework$14338
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
__CFRunLoopDoTimer
__CFRunLoopDoTimers
__CFRunLoopRun
CFRunLoopRunSpecific
RunCurrentEventLoopInMode
ReceiveNextEventCommon
_BlockUntilNextEventMatchingListInModeWithFilter
_DPSNextEvent
-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
XojoFramework$4746
XojoFramework$4747
Application._CallFunctionWithExceptionHandling%%o<Application>p
_Z33CallFunctionWithExceptionHandlingPFvvE
XojoFramework$4746
-[NSApplication run]
RuntimeRun
REALbasic._RuntimeRun
_Main
main

opening the project file, it seems a regular text file, similar to other projects

Is there any way I can recover all my work?
Any suggestions?

Could it be another file other than the project_file that is corrupted? How do I track down which one is?

Just to be clear, this is likely the reason your project is corrupted. The IDE does not account for folders where files could be locked & unlocked while it’s attempting to write.

That said, you’ll either need to go back to an archived version or see if you can get Xojo to recover it for you, but keep in mind that if there’s data truly gone, there may be nothing they can do either.

There are many users reporting corrupted files in this forum. Looks like there is a little chance that your proyect got corrupted each time you save it. Using shared folders/files or apps like dropbox increase this chance. First time it happened to me, I lost 2 weeks of work, second time, just a couple hours. Work around, use a version control system or backup the file each time you save it.

Start with the last working backup, if your proyect was saved in a TEXT format, try to open it in a text editor, check if your work is there and manually extract the modified/added methods you worked on and paste them in the working proyect.

If it was binary there’s not much that can be done… Check the size of the file, When I got corrupted proyects xojo didnt write the whole thing and the file was like 50% of the previous vorking version.

It looks like your project is a Xojo Web 2 project saved as text (several text files and not only the one ending in .xojo_project), if you are just trying to revert your main .xojo_project file to a previous version in dropbox, this will not work, you need to revert all the text files to the same point in time when it worked.

Learning and using version control will be ideal to have more control over your previous versions.

I hope you have a backup or can restore your files to a working version. Good luck.

Don’t you have a TimeMachine backup, where your file(s) may have versioning variants and possibly be not corrupted?

Dropbox has versioning, too.

Yes, but Alexandre mentions he tried previous versions in Dropbox and they’re also corrupted. My next attempt would be to check TimeMachine, where overwriting previous versions isn’t allowed.

1 Like

Yes but if it is a text project the whole folder will need to be restored, not just the project file. As someone already mentioned. We don’t know if that was tried?

Thank you, everyone, for your willingness to help. My files are saved as TXT files, a change I implemented recently. I had intended to learn GIT, but I ran out of time. Before this, I relied on Dropbox history and a single binary project file. I’m aware that it’s not an optimal system, but it was the one I had while on the move. This approach had its advantages and disadvantages, and there was one aspect I hadn’t considered, which is now apparent.
The advantage: I can open all files in a text editor and see their contents. Theoretically, I could recover part of my work by copying, pasting, and rebuilding the windows.
The disadvantage: The project is distributed across numerous different files.

The aspect I didn’t foresee but is now clear: Since the project is saved in TXT files, there is one file for each window or class. Before using TXT, I used binary and often saved project files with different names for backup purposes. Now I see that with TXT, this doesn’t help, because only the project file name changes, while the rest of the structure remains the same. Hence, even though I saved many times over the last few days, only the project file name was altered.

I’ve tried some things and I have a few questions that perhaps you could help with:

I attempted to open the project in Windows, even though it was created on a Mac. I thought that if there were a bug specific to the Mac, I might be able to open and save it on Windows. Unfortunately, that didn’t work. The same error occurred, but at least it displayed the names of the windows (files) it was attempting to open.

Here’s my question: I opened all files in a text editor and they all seem fine. I find it hard to believe that a CRC check would fail if a TXT file deviates slightly from its original form. In other words, if I edited those TXT files in any editor, Xojo should be able to open them without any issues, right? If so, why is it crashing when opening the files if all files seem fine with no strange characters or anything of the sort? Can’t I locate the problematic file and attempt to fix it? After all, it’s a TXT file; it should be repairable…

In the process of writing this post, I realized I could import all the files into a new project. Is this a viable strategy for recovering work? I tried importing everything, and it worked. My question is, if I can import all the files and they aren’t corrupted, could the problem lie with the IDE rather than the files themselves?

While writing this post, I managed to recover my work by reimporting all the individual files. Some classes were incorrectly imported as external files, but that wasn’t an issue because I still had them in my older binary project file, which hadn’t been modified in a long time. I simply copied and pasted from the old files. Even though I’ve resolved my issue (thanks to everyone who assisted), I’m leaving this post here as a reference for anyone else going through a similar ordeal.

What I do is have a build number. Every so often I decide that what I have at that moment is that build. So I zip the folder containing the project files together with all the other files needed to build the project and name the zip file after the build number. Then I increment the build number and continue. The app displays the build number at startup so I know what I’m running. So that looks like this:

The source folder, the Builds folder, and the Support Folder (with documentation, test code snippets, etc) are all saved onto an external SSD, onto two memory sticks that I carry with me when away from home, to Dropbox (not as a working repository, but as an offsite store), and to space I have with a hosting provider. Then there’s TimeMachine backups too.

What backups do you have?

1 Like

This is correct.

It’s very likely a problem within the structure of a file, which the IDE can’t resolve. (Sad it crashes in such situations…)

No need to “learn Git”.

  1. Create an Account on GitHub.com
  2. Create a New Project on GitHub.
  3. Setup a UI App like https://git-fork.com/ for Git.
  4. Clone the empty Project to your local Drive.
  5. Move all Project Files into your clone Folder.
  6. Push your Project to GitHub using the UI App.

From now on push local changes as needed to GitHub. In case of emergency you can pull files/projects as needed from GitHub. If you work in Groups, it may be a bit more complex. But i assume, in this case you would already use a VCS. :wink:

This is NOT correct. The IDE expects that it is the only entity editing those files and any edits, however trivial, have the potential of making them unreadable. Text within quotes, probably fine. Code lines? Maybe. If you changed the structure at all, the IDE won’t open the file.

Not necessarily. Importing a file does not have the same requirements as opening an entire project. For instance, when importing, the IDE will rename things to avoid conflicts. When opening an application costing project, it relies on the manifest file (.xojo_project) to be the single source of truth.

1 Like

I would still say “This is correct” because “Xojo should be able”… :wink:

2 Likes

Xojo text code is not a pure text code as other tools, it contains lots of “internal” human unreadable codes, hints and delimiters, those #TAG this, #TAG that, and alikes. If the user unbalances those control things the code gets broken.

1 Like

You can think what you want, but the IDE wants the files to follow the structure in the way it writes them.

If you open a PDF file and start adding and deleting things, you run the risk of corrupting them too. This is the same thing. Be safe, just don’t do it. Ignore this advice at your own peril.

1 Like

I hear what you say. Of course, you must not change the structure of the data, otherwise the IDE cannot interpret it correctly. But if I apply what you say to other projects, I would even have to say that HTML, XML and the like shouldn’t be edited with a text editor either. And that’s not right…

The user must be very careful when using other editors, but if the structure is preserved, the IDE should be able to read and process the files even if they have been edited externally.

But we’re drifting and I know what you’re getting at. Thanks @Greg_O :slight_smile:

I had a similar “message” and problem with Xojo when I tried to open a project with Dropbox sync disabled AND the project was set to “only online”.
Problem started with the last update of the Dropbox Client.
Works again, when Dropbox sync is on or the Project folder is “offline available”.

Your working copy of anything (Project, database, etc) should be isolated from “Externally Synchronized Folders” as Google Drive, iCloud, Dropbox, etc or you may be asking for data corruption.

You may have some sort of synchronized “Docs and back folder” where you copy things to. There you put copies of your work that you want to save. You should not work directly on them, specially when such structures are multi-file, holding some synchronization between the parts (as manifests, states, uncommitted transactions, etc).