Closed wwderw closed 3 years ago
I'm going to need some information:
Current KDE Neon User version
Yes, it is the official Godot Asset version
Technically it's not the Godot console, as in via the Godot program itself. I will open via Konsole the program and it would give me the msg that the database opened and then the next line, segmentation fault and that's it.
I have not used any legacy versions, just the one via the Asset Lib.
Tried the legacy version and still same result.
Attached is the same msg that I get with the Linux Release version.
Could you try to run the demo project? As downloadable in the releases tab here.
Oh! and also try to change your database path to ":memory:"
and see what happens
Wait, just to clarify: when you are talking about "Linux Release version" you are talking about an exported build of your game in release mode? Or are you talking about the plugin being compiled in release mode?
Linux Release version is the exported Godot project for the Linux platform.
I'm trying to do some exporting on an Ubuntu machine to see if I get the same issues...
Ok, I've exported the demo-project on my Ubuntu 20.04 test machine. In both cases the demo project runs perfectly:
DEBUG:
RELEASE:
And the :memory: database works, so I guess the next question is:
Also I would maybe recommended just downloading the demo-project and exporting it in both release and debug mode and seeing if you have same issues?
Yes, demo does work perfectly for me as well.
Location: res://assets/otrDB.db code: var db := "res://assets/otrDB.db"
I actually move my project (the exported version that is), with the file structure to another spot in my system. The debug version works flawlessly. The Release version does that error. I have to try the Windows version on a separate computer (not even in a shared folder in a VM) and both versions work.
That is what has me confused is that both versions of release types work on Windows, but only debug works on Linux. I would have thought that it would have been universal, but computers can be quirky things thats for sure.
Okay, I'm grasping at straws here because I got no idea what's going on, but:
I really got no clue on this one... If the demo-project works perfectly in both debug and release then your project should work as well... unless something weird is going on with your database....
Do you use any non-conventional symbols in your database? (Arabic, Korean, Chinese, ... or just weird letters with umlaut for example)
That could be possible that something got through. This isn't for a game, but an application, so the database is slight different then what one would expect with a game. Although I created the original DB in Sqlite Studio, I did import CSVs from the previous database.
Does your database use the default settings? (header size, segment size, ... etc, like here for example) Could you open your database using an external tool? (like https://sqlitestudio.pl/ or the KDE equivalent)
I actually created this in Sqlite Studio (for Linux) and the database settings were default to the best of my recollection.
Does the error also appear if you don't copy your project to this new location? This might be the DB itself. The error didn't appear. It created the db and said that it opened and closed it.
Just has me stumped on the fact that it works on both versions of Windows and on the debug version of Linux. I would have thought it would have been universal not working, but then again, I only know enough to cause damage.
As far as paths go and changing them up, everything is the same.
The other thing that gets me to is that the same database does work using Qt/C++ and Python/Tkinter (I switched to Godot because I was wanting the Mac support).
I just don't know. I wouldn't put it past my doing something, but I just don't know.
mmmh.. is this possible to share this database so I can test it out on Ubuntu myself? Or does it contain sensitive information that you would rather not share?
Not at all. The database is of just OTR logs.
Release build using this database works on Ubuntu 🤷
Does KDE Neon use bleeding edge? What's the version of glibc for example? Also, maybe you could recompile the plugin on your device and see if that fixes it, cause I don't know what else I can test on my side . . . 😢 (instructions here)
Some things are bleeding edge (typically the Qt apps), but the Ubuntu base is the latest LTS, but glibc could be the latest and greatest. I'll download an LTS and spin up a VM later on today and see if that does it and let you know.
That does make sense though.
I'll let you know later on.
Little addition to the error msg. Segmentation fault (core dumped), which if I'm understanding correctly is a permissions issue, but I checked my db permission and owner/group/others have full permissions. I just don't know, I'm at a loss. I would have though again, if it was a permission issue it would have also extended to debug mode as well.
Bummer. Thanks for all the help though, I appreciate it.
@wwderw I've just tested with KDE Neon myself (KDE neon user edition 5.21).
I don't seem to get any segmentation faults 🤔 🤷 maybe something wrong with your KDE neon installation? Or your Godot or Export Templates are borked in some way?
Sorry it took me so long. I tried it in a Mint VM, Kubuntu LTS on bare metal and on my son's Neon NUC, all had the same issue.
I would think that it was my code if it wasn't for the fact that it worked in Debug mode and it worked as a release on Win 10.
damn... well... is it possible to send me a minimum reproduction project? because I have no clue how to reproduce the error.
Maybe there's something weird going in your project that crashed it in release mode.
Also could you try godot 3.2.4? They fixed some discrepancies between debug and release in that new version. (Check warnings/errors in debugger console! Warnings or errors that might not crash the application in debug mode, WILL crash the application in release mode)
I had tried the RC 7 of 3.3 and it did the same thing.
For getting the master list of all included tables, this is the snippet of code for the function (this is the first function that I try and it crashes every time in Release mode on linux.
$labels/master.show() $labels/exists.hide() $labels/date.hide() $labels/number.hide() $labels/name.hide()
tree = Tree.new()
root = $databaseView.create_item()
root.set_text(0, "Series Name")
tree.set_hide_root(true)
child = $databaseView.create_item(root, 0)
$databaseView.clear()
dbLogs = SQLITE.new()
dbLogs.path = db
dbLogs.open_db()
dbLogs.query("SELECT Name FROM SQLite_master ORDER BY 1 ASC")
for i in range(0, dbLogs.query_result.size()):
var newValue = dbLogs.query_result[i].values()
for new in newValue:
var show = $databaseView.create_item(child)
show.set_text(0,new)
dbLogs.close_db()
OS.set_window_title("otrDB - Master Log")
Hello! :) The code snippet you provided me is a bit hard to work with. I don't see anything wrong atm with that code though. If possible, would giving me your entire project (or a stripped version that at least runs in the editor) be acceptable?
I have this suspicion that your issue might be related to this instead: https://github.com/godotengine/godot/issues/28612
Stripped down version that only gets the master list. It works in debug mode and within the editor's testing, but does not work in Release mode.
@wwderw For the moment I'm just testing on Windows, but I already noticed something weird going in release mode:
DEBUG (everything is fine I think):
RELEASE (for some reason 'A Christmas Carol' is now a parent??? And this switches randomly):
Also I removed some memory leakage in the project, but I don't think it is related to the crash. The tree variable is unnecessary at the moment, so I'm not sure why it was added?
(^ script with removed tree)
Will report back once I test this on Linux.
Getting the same error now! Will debug ASAP
Okay, I found the issue.
Modified script that doesn't crash due to segmentation fault:
extends Node2D
const SQLITE = preload("res://addons/godot-sqlite/bin/gdsqlite.gdns")
var db := "res://assets/otrDB.db"
var dbLogs
var root
var child
func _ready():
pass
func _on_master_pressed():
root = $databaseView.create_item()
root.set_text(0, "Series Name")
dbLogs = SQLITE.new()
dbLogs.path = db
dbLogs.open_db()
dbLogs.query("SELECT Name FROM SQLite_master ORDER BY 1 ASC")
var result = dbLogs.query_result.duplicate(true)
for i in range(0, result.size()):
var newValue = result[i].values()
for new in newValue:
var show = $databaseView.create_item(root)
show.set_text(0,new)
dbLogs.close_db()
OS.set_window_title("otrDB - Master Log")
Why does this script work?
clear()
on the Tree removes ALL of the items in the tree. This means that the child
variable becomes AN INVALID instance! Attempting to call create_item()
in your Tree with the child
variable as the parent is an invalid call.duplicate()
on the query_result as it might get overwritten otherwise when you call consecutive queries. (If you don't plan to call additional queries in your for-loop, then ignore this comment)Why does only generate a segmentation fault in Linux? 🤷 I'll see if I can open an issue or find an existing one on this subject in the main Godot repository.
I've added an even more minimal reproduction project here: https://github.com/godotengine/godot/issues/47693
We'll see what they say 🤷
The tree variable was for the Tree node. I was just following the help documentation on that one.
The reason for the clear() was that any subsequent calls to the DB may not clear out all of the previous one. Say for instance, you called the master list, and then you called an individual log that only had 92 items. The 92 items would overwrite the first 92 items of the master log, but the rest of the master log would be there. The only way that I found to handle that was the clear() function.
The tree variable was for the Tree node. I was just following the help documentation on that one.
The reason for the clear() was that any subsequent calls to the DB may not clear out all of the previous one. Say for instance, you called the master list, and then you called an individual log that only had 92 items. The 92 items would overwrite the first 92 items of the master log, but the rest of the master log would be there. The only way that I found to handle that was the clear() function.
Yes, but you'll have to explicitly set the child
-variable (and root
if you need it) to NULL then, otherwise Godot will crash 🤷
So in the end it seems to be Godot's fault that the RELEASE export crashes on Linux (and behaves weirdly on Windows)
Hmmm, just checked the Godot issue that you created and apparently it also affects the Mac release only and not the debug.
So it appears to be, based on the tags, that they believe it has to do with Godot core. Based on that, I don't know if you want to close out this issue or not.
Hmmm, just checked the Godot issue that you created and apparently it also affects the Mac release only and not the debug.
So it appears to be, based on the tags, that they believe it has to do with Godot core. Based on that, I don't know if you want to close out this issue or not.
Okay! I'll close the issue then :) If there's any other problem you run into, please feel free to open a new bug report 🎉
Will do, thanks again for all your help. I really do appreciate it.
Using Godot 3.2.3, I'm getting a segmentation fault right after accessing the database (doesn't matter the operation) when I use an exported Release version. Linux Debug works without issue. Windows Release and Debug have no issue at all either.
Unable to confirm on Mac.
Any starting points as to why it only seems to affect the Linux Release version? I would have thought that if it was associated to a memory leak or trying to to access something that I shouldn't have within my code, it would be an issue across platforms or am I wrong in that assessment?