Search the Community

Prior to 11.2, I used Android Monitor to access Log.d messages from my Android apps. Monitor appears to have been deprecated, and so I have attempted to access logging through adb logcat. While this returns a large amount of logs, copying the output and performing a search for logs from my app returns nothing. I've also attempted adding parameters to filter on the app itself, such as: adb -d logcat <app name>:I *:S which returns: --------- beginning of main --------- beginning of system But nothing else. I have also tried Device Lens 1.3.0 (mentioned by Dave Nottage here), which detects the Android device, displays all processes & allows a screen capture, but clicking the play icon to display notifications only shows one message, and that's it. I had no problems accessing logs using this device and app with the previous version of RAD. I would be very grateful for any help with this matter, thanks in advance.

Hi Folks, in one ouf our projects I'm using @Daniele Teti 's loggerpro library (https://github.com/danieleteti/loggerpro) instead of a homebrew logging solution. A few weeks after switching to loggerpro, a first Eurekalog bug report came in with the message: "EMonitorLockException in ThreadSafeQueueU.pas: {ThreadSafeQueueU}TThreadSafeQueue<LoggerPro.TLogItem>.Enqueue, Zeile 157 (0)". This exception is clearly raised inside loggerpro. I have already asked at GitHub (https://github.com/danieleteti/loggerpro/issues/53), but have received no reply yet. Every month or so, another of these bug reports comes in. The problem is: - I cannot reproduce/trigger it on my development PC, even though I think I can locate exactly, where and under which circumstances it happens - I don't see any obvious error in the loggerpro code - I don't see any obvious error in my code which is why I'm asking for help here. Maybe I have missed something obvious in my code... We have the following scenario: The main thread starts a background task (IFuture), which builds up an index of files for later use. Both, main and background task log their status with LoggerPro. The index updater: procedure TUpdater.Update; var LXxxFiles, LYyyFiles: TFileList; begin if FStatus = stNotLoaded then begin Log.Debug('Renewing Index', 'INDEX'); LXxxFiles := TFileList.Create; LYyyFiles := TFileList.Create; try FStatus := stLoading; ... Prepare XXX and YYY lists ... Log.Info('Check %d Xxx Files', [LYyyFiles.Count], 'INDEX'); Log.Info('Check %d Yyy Files', [LXxxFiles.Count], 'INDEX'); // Check existing files and index their content if FStatus <> stCanceled then if Process(LXxxFiles) and Process(LYyyFiles) then FStatus := stLoaded; if FAutoSave then FIndex.Save; FIndex.LogStats; Log.Debug('Status - ' + TRttiEnumerationType.GetName<TLoadStatus>(FStatus), 'INDEX'); finally LXxxFiles.Free; LYyyFiles.Free; end; end; end; If the main task needs the index, it calls the following routine: function TUpdater.WaitForCompletion: boolean; begin Log.Enter('Updater.WaitForCompletion', 'INDEX'); // Waits until the IFuture task is finished and returns its status // The calling thread is blocked while waiting Result := (FTask.Value = stLoaded); Log.Exit('Updater.WaitForCompletion', 'INDEX'); end; Log.Enter and Log.Exit are just two wrapper functions around Log.Debug that I have added to LoggerPro. The Exception occurs on the `Log.Exit` call Here are the relevant lines of the Eurekalog report: EMonitorLockException Object lock not owned. |005B7380|Application.exe|ThreadSafeQueueU.pas |{ThreadSafeQueueU}TThreadSafeQueue<LoggerPro |TLogItem>.Enqueue |157[0] | |005B61B5|Application.exe|LoggerPro.pas |TLogWriter |Log |557[5] | |0110346B|Application.exe|System.Generics.Defaults.pas | | |39[0] | |010FF5A2|Application.exe|Update.Index.pas |TUpdater |WaitForCompletion |845[4] | |010FF560|Application.exe|Update.Index.pas |TUpdater |WaitForCompletion |841[0] | Normally the update task takes some time, so the typical log output is: 2022-04-21 15:22:13:937 [TID 16780][INFO ] [INDEX ] Updater.Update in: C:\Users\Public\Documents\##### 2022-04-21 15:22:13:937 [TID 16780][DEBUG ] [INDEX ] --> Updater.StopUpdate 2022-04-21 15:22:13:937 [TID 16780][DEBUG ] [INDEX ] <-- Updater.StopUpdate 2022-04-21 15:22:13:987 [TID 16780][INFO ] [INDEX ] Contains 240 Files 2022-04-21 15:22:13:987 [TID 16780][INFO ] [INDEX ] Contains 4931 Entries 2022-04-21 15:22:13:987 [TID 3280][DEBUG ] [INDEX ] Renewing Index 2022-04-21 15:22:13:987 [TID 16780][DEBUG ] [INDEX ] --> Updater.WaitForCompletion 2022-04-21 15:22:14:080 [TID 3280][INFO ] [INDEX ] Remove 0 Files 2022-04-21 15:22:14:080 [TID 3280][INFO ] [INDEX ] Check 238 xxx Files 2022-04-21 15:22:14:080 [TID 3280][INFO ] [INDEX ] Check 2 yyy Files 2022-04-21 15:22:14:242 [TID 3280][INFO ] [INDEX ] Contains 240 Files 2022-04-21 15:22:14:242 [TID 3280][INFO ] [INDEX ] Contains 4931 Entries 2022-04-21 15:22:14:242 [TID 3280][DEBUG ] [INDEX ] Updater.Status - stLoaded 2022-04-21 15:22:14:242 [TID 16780][DEBUG ] [INDEX ] <-- Updater.WaitForCompletion ... Normal work continues here In some cases (no search paths defined or search paths empty), there's "nothing" to do, which results in the following log output: 2022-04-21 14:18:14:972 [TID 22208][INFO ] [INDEX ] Updater.Update in: C:\Users\Public\Documents\##### 2022-04-21 14:18:14:972 [TID 22208][DEBUG ] [INDEX ] --> Updater.StopUpdate 2022-04-21 14:18:14:972 [TID 22208][DEBUG ] [INDEX ] <-- Updater.StopUpdate 2022-04-21 14:18:14:973 [TID 22208][INFO ] [INDEX ] Contains 0 Files 2022-04-21 14:18:14:973 [TID 22208][INFO ] [INDEX ] Contains 0 Entries 2022-04-21 14:18:14:974 [TID 14984][DEBUG ] [INDEX ] Renewing Index 2022-04-21 14:18:14:974 [TID 14984][INFO ] [INDEX ] Remove 0 Files 2022-04-21 14:18:14:974 [TID 14984][INFO ] [INDEX ] Check 0 xxx Files 2022-04-21 14:18:14:974 [TID 14984][INFO ] [INDEX ] Check 0 yyy Files 2022-04-21 14:18:14:977 [TID 14984][INFO ] [INDEX ] Contains 0 Files 2022-04-21 14:18:14:977 [TID 14984][INFO ] [INDEX ] Contains 0 Entries 2022-04-21 14:18:14:977 [TID 14984][DEBUG ] [INDEX ] Updater.Status - stLoaded 2022-04-21 14:18:14:979 [TID 22208][DEBUG ] [INDEX ] --> Updater.WaitForCompletion 2022-04-21 14:18:14:979 [TID 22208][DEBUG ] [INDEX ] <-- Updater.WaitForCompletion ... Normal work continues here Note that in this case the updater was finished (stLoaded) before WaitForCompletion was called. The Log.Enter "--> Updater.WaitforCompletion" line may occur anywhere between the lines of the background thread (TID 14984 in this case). This is the LoggerPro output matching the bug report. The `EMonitorLockException` occured on the `Log.Exit` call in `TUpdater.WaitForCompletion` and this line is missing from the log: 2022-04-21 14:42:03:003 [TID 20620][INFO ] [INDEX ] Updater.Update in: C:\Users\Public\Documents\##### 2022-04-21 14:42:03:003 [TID 20620][DEBUG ] [INDEX ] --> Updater.StopUpdate 2022-04-21 14:42:03:003 [TID 20620][DEBUG ] [INDEX ] <-- Updater.StopUpdate 2022-04-21 14:42:03:004 [TID 20620][INFO ] [INDEX ] Contains 0 Files 2022-04-21 14:42:03:004 [TID 20620][INFO ] [INDEX ] Contains 0 Entries 2022-04-21 14:42:03:004 [TID 3312][DEBUG ] [INDEX ] Renewing Index 2022-04-21 14:42:03:004 [TID 3312][INFO ] [INDEX ] Remove 0 Files 2022-04-21 14:42:03:004 [TID 3312][INFO ] [INDEX ] Check 0 xxx Files 2022-04-21 14:42:03:004 [TID 3312][INFO ] [INDEX ] Check 0 yyy Files 2022-04-21 14:42:03:008 [TID 20620][DEBUG ] [INDEX ] --> Updater.WaitForCompletion 2022-04-21 14:42:03:008 [TID 3312][INFO ] [INDEX ] Contains 0 Files 2022-04-21 14:42:03:008 [TID 3312][INFO ] [INDEX ] Contains 0 Entries 2022-04-21 14:42:03:008 [TID 3312][DEBUG ] [INDEX ] Updater.Status - stLoaded ... Normal work continues here Note that the updater was still working (on nothing ;-)) when WaitForCompletion was called. It looks like Log.Exit('WaitForCompletion') and Log.Debug('Updater.Status - stLoaded') happen in the same millisecond, so I assume that thread 3312 still held the lock, when exception thread 20620 called `Log.Exit`. But I see this all the time (finish/exit happens in the sme millisecond) when I run the code on my PC and never get an EMonitorLock exception. Is there something we are doing wrong or have we come across a race condition in LoggerPro or the Delphi locking implementation?

I want to use Google Cloud logging from Delphi. From https://cloud.google.com/apis/docs/client-libraries-explained While you can use Google Cloud APIs by making direct HTTP requests to the server (or RPC calls where available), we provide client library code for all our Cloud APIs that makes it easier to access them from your favorite languages Of course Delphi is not represented. Any hints on how I can use cloud for logging? It also mention that https://www.fluentd.org can be used from any language. But I still want samples how to use all this in practice. Any help appreciated!

I'm fairly new to RAD Server and while I have a small module working, pulling data from a database, I'd like to be able to do some logging. Sure, I can create another endpoint and dump stuff in a JSON result, but that's not really behind-the-scenes logging. And yes, I could create a log table and insert records in there. But there's an intriguing class in the EMS namespace called TEMSLoggingService. I can't find any documentation or examples that explain what this is for or how to use it. Anyone have any wisdom on this to share?

When in DEBUG mode one of my app generates a log of log entries using CodeSite. The logging process is OK, but the Live Viewer's update is tooooooooo slow - even after the app existed the Live Viewer still took 5 more minutes to finish receiving the logs. Any way to improve the performance?