A friendly heads up for nightly users [Bug testers needed!]

@MuratUrsavas not that simple.

  1. Locale
    There are two settings that deremine locale
    One is OS setting (pl_PL in my case; comma as OS decimal separator)
    Other is KICAD language setting (English in my case; defines ‘dot’ as decimal separator used in Kicad’s interface).
    So having pl_PL in OS, and English in Kicad, I have Comma in most apps like Excel and Dot in Kicad.
    Now how about your setup? OS tr_TR uses comma; how about Kicad’s interface setting?

  2. How to you determine when the library is reloaded?
    I understand the assumption is the issue happens when doing file save operation. How is the library reload triggered?
    Does the issue manifest once symbol is placed on the sheet? Or within the library browser?

Like you said, tr_TR uses comma, KiCad language setting is set as “Default”. I’m guessing this should default it to en_US, but comma is the actual nightly decimal separator. So apparently it’s not exactly the case.

What do you mean by “reload”. If you mean closing it and reopening again, it gets corrupted due to file state. And this is all happening within Symbol Editor, no need for Schematic Editor or Lib Browser. (Hopefully due to new format’s nature the symbols on the sheets don’t get updated unless you want it explicitly. You can use them as rescue sources like I did couple times).

I have Turk on kicad’s language list, shouldn’t it default to Turk on tr_TR OS locale?
I have set to English and my decimal separator is ‘dot’. Can you force English and see if the separator changes accordingly? Or maybe Linux is different (and under Linux kicad uses default OS separator, not kicad’s separator).

My system language and locale is en_US. But the numeric locale is tr_TR. This is in the pocket and possibly related with this issue.

But one thing is there and staring us. If the locale is the base cause, then how come we read the library file without a problem? So locale is a parameter for sure but load/store codes diverges at somewhere and we need to find that forking point.

P.S: One more thing to fix :slight_smile: It should be “Türkçe” not “Türk”. (Was planning to translate to Turkish completely)

Could it be a threading issue? Because LOCALE_IO is quite a hack whick could fail when a different thread also sets a locale.

Personally, this hack should be removed in the future. The Altium importer for example does not depend on it.

This hack was created in the days before we could imbue a stream with a specific locale. This is no longer required. And there are parts of KiCad that sidestep the issue (ReadDoubleFromString)

But without a reproducible procedure, we are feeling around in the dark and we won’t know if/when we’ve fixed it.

Due to dangling reproduction rate of the issue, I’m suspecting that from the very beginning. But could not solve underlying multi threading mechanism for a simple file store. Sure, it’s due to my lack of KiCad code knowledge, but this part should be synchronous in a single worker thread.

@MuratUrsavas does the reproduction rate change from build to build?
Maybe it would be good idea to go back to builds where the rate was greater, just to find the right pattern for repro.
Have you changed the library size so it might e.g. impact processing time?

No visible pattern. I was suspecting an ordering issue of body symbols but Wayne said it was fixed in the mean time, before the latest reports.

Since there is no visible pattern, it is pretty hard to know that. We have to keep an eye on the library constantly, but not frequently editing a symbol library while working. So we can’t define commits safe or suspicious.

It grew over time but not much. I don’t think this is a parameter here. CPU load from the external processes would have much more effect on this.

I once wrote something threaded on a single core machine (it was old even back then). No problems. Then I bought a new dual core machine and continued. Immediately problems arose, deadlocks or something like that. Lesson learned: threading problems may depend on hardware. It’s quite logical that when threaded code is really run sequentially (single core) some potential problems never occur. And the more there is real concurrency, the higher the chance of running into certain problems. It’s not also difficult to imagine how low level (compiled) instructions and how they are actually executed on hw may affect threading problems.

For the record, I’m still using that same dual core. How about you?

It’s a 6 core (12 HT) Intel Core i7.

In my programming style, I try to plan the system as tasks related with resources. Making a single resource (e.g. file system) multi threaded wouldn’t give you any advantage since its a single resource, you can’t multiply it. But if you do, it would create a lot of headache due to the nature of entropy (like clans fighting over an oasis in the middle of a desert).

Also I always assume that there are unknown bottle necks in the threads and they are always asynchronous. Otherwise, like in your case, it will bite when it finds the first chance :slight_smile:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.