Bug: silent fail on using special Unicode characters

Notes, tips, and other usefull things on how to use LogMX

Moderator: admin

Post Reply
MShekow
Posts: 1
Joined: Mon Jan 14, 2019 10:04 am

Bug: silent fail on using special Unicode characters

Post by MShekow » Mon Jan 14, 2019 10:09 am

Hi,

I've encountered a problem where LogMX fails silently when using special characters in the message. At first I thought this was a problem with my own Java parser, but the problem can also be reproduced easily as follows:

1) Create a new simple parser. Click "add field 5 times" to have Timestamp, Thread, Emitter, Level and Message. Set "yyyy-MM-dd HH:mm:ss,SSSS" for the timestamp's dateformat.
2) Paste the following lines

Code: Select all

2019-01-10 08:57:37,954 Thread-SyncWebdavAndHttpClient_0 GenericRequestOperation DEBUG PROPFIND(https://server/Templates 2018/Nederlands/PlanMaker) finished (1797 bytes returned)
2019-01-10 08:57:37,961 Thread-SyncWebdavAndHttpClient_0 GenericRequestOperation DEBUG PROPFIND(https://server/Templates 2018/الإنجليزية/PlanMaker) finished (1915 bytes returned)
This should result in the first line being shown correctly, and the second one producing empty fields with white background. From this point onwards, even valid entries won't be parsed anymore, parsing is completely broken...

Tested it with LogMX 7.3.0 on Windows 7.

Best regards!
Marius

admin
Site Admin
Posts: 507
Joined: Sun Dec 17, 2006 10:30 pm

Re: Bug: silent fail on using special Unicode characters

Post by admin » Tue Jan 15, 2019 12:36 am

Hello,

You are right, this is indeed a bug.
Sorry about that. It will be fixed in the version following v7.4.0 (7.4.0 is already in the pipe to be released in a few hours).
I will post a message in this thread to let you know.

Xavier

admin
Site Admin
Posts: 507
Joined: Sun Dec 17, 2006 10:30 pm

Re: Bug: silent fail on using special Unicode characters

Post by admin » Thu Mar 07, 2019 2:00 am

Hello,

Sorry for the late fix, LogMX v7.6.0 has just been released and includes a fix for this bug.
(in case you're wondering, version 7.5.0 was a quick hotfix for another issue, and could not include a fix for this encoding issue because of time constraints).

Xavier

Post Reply