[logging-persist] and other errors in latest Fire

I’m getting a lot of debug messages in the latest Fire build like these (in fact I think they are in the last few builds):

2020-02-24 17:37:22.231173+0000 Logonn[51419:2979722] [logging-persist] cannot open file at line 43353 of [378230ae7f]
2020-02-24 17:37:22.231440+0000 Logonn[51419:2979722] [logging-persist] os_unix.c:43353: (0) open(//H\M-iЇ\M^?\^?) - Undefined error: 0
2020-02-24 17:37:22.231797+0000 Logonn[51419:2979722] [logging-persist] cannot open file at line 43353 of [378230ae7f]
2020-02-24 17:37:22.232005+0000 Logonn[51419:2979722] [logging-persist] os_unix.c:43353: (0) open(//H\M-iЇ\M^?\^?) - Undefined error: 0
2020-02-24 17:37:22.232326+0000 Logonn[51419:2979722] [logging-persist] cannot open file at line 43353 of [378230ae7f]
2020-02-24 17:37:22.232565+0000 Logonn[51419:2979722] [logging-persist] os_unix.c:43353: (0) open(//H\M-iЇ\M^?\^?) - Undefined error: 0

and noticed this code causes an error (exact one I can’t get right now as debugger not stopping on my breakpoint for some reason):

  try
    sqlite3_shutdown();
    if sqlite3_open_v2(fCountsDBFileName, @fCountsDB, SQLITE_OPEN_READWRITE or SQLITE_OPEN_FULLMUTEX, nil) = SQLITE_OK then begin

I can probably build a test case if it helps and isn’t something obvious to you, to do with the recent changes (.2473 for example was fine), but just ran out of time to narrow it right down as got to go just now…

Never seen it heard of these. But iOS and macOS are getting more and more “noisy” with NSLogs outside of the apps control with each release :(. What kind of project is this? In any case, it’s not something that be coming from fire, or any of our libs, I’d say.

I’ll sort a test case then, as I can see it is each time I call sqlite3_open_v2, I get two errors as above (the above is three separate calls) and it is something that’s changed in Fire’s compiler recently. If I use the external compiler (.2471 is what I have currently) then it works perfectly well. There’s something it doesn’t like opening the SQLite file.

Does the actual SQLIte call fail? or is it just that the extra log message gets emitted? I don’t really see how a compiler change/bug could cause that…

It fails. I’ve tracked down what happens and produced a test case finally. At its simplest, if you try to open a database that doesn’t exist yet, in order to create one, then it produces this error.Archive.zip (1.0 MB) I have just made some modifications to your sqlite example, to demo this.
If you run this in latest Fire, it fails (line 76 of masterviewcontroller) but it works with the external compiler (or an earlier fire). You need to ensure there’s no DB file to see it (which there won’t be the first time).
Sorry, odd ‘begin’ just appeared from somewhere, so just updated the zip file

Thanx. Whats the exact old and new compiler versions you tested with?

Fire is latest, .2487 and I’m just working out which one it started with. External is .2471

1 Like

.2477 and later fail
.2473 works

So, somewhere between those I guess is when the issue appeared.

Hmm, I cant reproduce any errors here, whether. build with 2471 or my latest (2487):

~> Please note: The debugger cannot capture StdOut (from `print()` or `writeLn()`) from the Simulator. `NSLog()` will be visible.
~> Process SqliteApp started
2020-02-25 09:02:50.880653-0400 SqliteApp[93924:2195412] SecTaskLoadEntitlements failed error=22 cs_flags=220, pid=93924
2020-02-25 09:02:50.883879-0400 SqliteApp[93924:2195412] SecTaskCopyDebugDescription: SqliteApp[93924]/0#-1 LF=0
2020-02-25 09:02:51.035230-0400 SqliteApp[93924:2195412] SecTaskLoadEntitlements failed error=22 cs_flags=220, pid=93924
2020-02-25 09:02:51.035529-0400 SqliteApp[93924:2195412] SecTaskCopyDebugDescription: SqliteApp[93924]/0#-1 LF=0
2020-02-25 09:02:51.163847-0400 SqliteApp[93924:2195412] /Users/mh/Library/Developer/CoreSimulator/Devices/2DCE6291-2902-4E13-860F-1D88FCCCA92B/data/Containers/Data/Application/BE24CD11-D0BB-4651-B1DB-B82868BEC4D9/Library/Application Support/sqlittest/PCTrade.db
2020-02-25 09:02:51.164096-0400 SqliteApp[93924:2195494] async!
2020-02-25 09:02:51.164265-0400 SqliteApp[93924:2195494] self: <MasterViewController: 0x7f80a9f07560>

and I get an empty table view.

You’re definitely deleting the file in between? I was doing it manually, but maybe I should have written this:

if NSFileManager.defaultManager.fileExistsAtPath(lDatabaseName) then 
   NSFileManager.defaultManager.removeItemAtPath(lDatabaseName) error(nil);
  if sqlite3_open(lDatabaseName, @lDatabase) = SQLITE_OK then begin
    var lStatement: ^sqlite3_stmt;
    if sqlite3_prepare_v2(lDatabase, createCust, -1, @lStatement, nil) = SQLITE_OK then
        sqlite3_step(lStatement);
    sqlite3_finalize(lStatement);
  end;

I get this:

~> Please note: The debugger cannot capture StdOut (from `print()` or `writeLn()`) from the Simulator. `NSLog()` will be visible.
~> Process SqliteApp started
2020-02-25 13:09:41.184010+0000 SqliteApp[64227:3944563] SecTaskLoadEntitlements failed error=22 cs_flags=220, pid=64227
2020-02-25 13:09:41.184436+0000 SqliteApp[64227:3944563] SecTaskCopyDebugDescription: SqliteApp[64227]/0#-1 LF=0
2020-02-25 13:09:41.223219+0000 SqliteApp[64227:3944563] SecTaskLoadEntitlements failed error=22 cs_flags=220, pid=64227
2020-02-25 13:09:41.223513+0000 SqliteApp[64227:3944563] SecTaskCopyDebugDescription: SqliteApp[64227]/0#-1 LF=0
2020-02-25 13:09:41.338807+0000 SqliteApp[64227:3944563] /Users/Jeremy/Library/Developer/CoreSimulator/Devices/A2A8486D-AD49-4153-B496-10D1DD200B0D/data/Containers/Data/Application/A3368A70-7AB0-4AD3-AB43-562836CB33E8/Library/Application Support/sqlittest/PCTrade.db
2020-02-25 13:09:41.339078+0000 SqliteApp[64227:3944721] async!
2020-02-25 13:09:41.339228+0000 SqliteApp[64227:3944721] self: <MasterViewController: 0x7fcbe7c08570>
2020-02-25 13:09:41.340257+0000 SqliteApp[64227:3944563] [logging-persist] cannot open file at line 43353 of [378230ae7f]
2020-02-25 13:09:41.340374+0000 SqliteApp[64227:3944563] [logging-persist] os_unix.c:43353: (0) open(//H\M-iЇ\M^?\^?) - Undefined error: 0
2020-02-25 13:09:41.340626+0000 SqliteApp[64227:3944563] [logging-persist] cannot open file at line 43353 of [378230ae7f]
2020-02-25 13:09:41.340737+0000 SqliteApp[64227:3944563] [logging-persist] os_unix.c:43353: (0) open(/Users/Jeremy/Library/Developer/CoreSimulator/Devices/A2A8486D-AD49-4153-B496-10D1DD200B0D/data/Containers/Data/Application/A3368A70-7AB0-4AD3-AB43-562836CB33E8/Library/Application Support/sqlittest/PCTrade.db) - Undefined error: 0

Ah sorry I missed the step; I thought your app would do that. repeduced.

Narrowed it down to

method MasterViewController.viewDidLoad;
begin
  inherited viewDidLoad;

  var createCust :String := 'CREATE TABLE Customers (Id TEXT PRIMARY KEY, Name TEXT)';
  var lDatabaseName := GetName;

  var lDatabase: ^sqlite3 := nil;
  if sqlite3_open(lDatabaseName, @lDatabase) = SQLITE_OK then begin
    var lStatement: ^sqlite3_stmt;
    if sqlite3_prepare_v2(lDatabase, createCust, -1, @lStatement, nil) = SQLITE_OK then
      sqlite3_step(lStatement);
    sqlite3_finalize(lStatement);
  end;
  
end;

I see some IR differences which seem to be related to passing NSStrings where ^AnsiChar is expected; it looks like the compiler used to implicitly concert those, but no longer does. If I change your code to

  var lDatabase: ^sqlite3 := nil;
  if sqlite3_open(lDatabaseName.UTF8String, @lDatabase) = SQLITE_OK then begin
    var lStatement: ^sqlite3_stmt;
    if sqlite3_prepare_v2(lDatabase, createCust.UTF8String, -1, @lStatement, nil) = SQLITE_OK then
      sqlite3_step(lStatement);
    sqlite3_finalize(lStatement);
  end;

it works fine.

I wasn’t;t even aware that this should work implicitly, but I’ll log an issue to either fix it or have the compiler fail/warn properly…

Thanks, logged as bugs://83989

Ah, I see, thanks. I’ll just change all occurrences to force those to be as expected. It’s always just worked. Compiler magic, presumably!

Not sure where you’ll be looking with this, but I’ve also found I have to make sure sqlite3_bind_text calls etc have ^AnsiChar passed to them.

Yeah, this will affect any API that accepts an ^AnsiChar, ie anything C-level.

Great, thanks for the confirmation.

1 Like

FTR, im assuming its an unplanned regression and will be fixed to work again w/o the .UTF8String call. But I’ll need to discuss it with Carlo tomorrow.

Sure, that makes sense, which is why I’m checking all my calls (all my problem ones are bit I wrote years ago), but a compiler warning would be good at the very least, given if you pass it an NSstring it fails.