Question: running debug builds on xplat without logging?

[rhuanjl]

I couldn't find the answer to this in the wiki or docs if it is there I'm sorry for missing it.

If I run a debug build of ChakraCore on macOS it produces a lot of logging that is rarely of use to me, below is a sample but one run of ch from a debug build with any script at all produces about 5 times this amount :

] Init /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:59Expression: InternalGetCurrentThread() == pthrCurrent
] SetSignalCount /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:563Expression: InternalGetCurrentThread() == m_pthrOwner
] ReleaseController /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:742Expression: InternalGetCurrentThread() == m_pthrOwner
] Release /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:100Expression: InternalGetCurrentThread() == m_pthrOwner
] Init /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:59Expression: InternalGetCurrentThread() == pthrCurrent
] Init /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:59Expression: InternalGetCurrentThread() == pthrCurrent
] CanThreadWaitWithoutBlocking /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:153Expression: InternalGetCurrentThread() == m_pthrOwner

Additionally if I run the test suite with a debug build it produces all of this logging - which causes every single test to fail as the logging is not in the baselines.

Please could someone tell me how to disable this so I can:

• ensure any new code I've written doesn't hit asserts whilst passing tests in the test suite
• use tracing or dump features without this noise
• debug CC without this noise

[fatcerberus]

Interestingly, debug builds of ChakraCore done with MSVC IIRC don’t produce all this logging (or any at all, even). This suggests it is indeed possible to disable it, but unfortunately I don’t know how.

[MikeHolman]

That debug logging is assertion failures. I think there is some bug with tracking current thread in the PAL.

[rhuanjl]

This is related to #6404

[ppenzin]

@rhuanjl doe you have a stack trace for the assert by any chance?

I've tried pulling the offending file out, and of course it failed to link, but maybe there is a way to rewrite some of this as part of ChakraCore, rather than PAL.

[rhuanjl]

@rhuanjl doe you have a stack trace for the assert by any chance?

These are PAL “asserte”s which check a condition then print that it failed if it did they don’t crash the programme or produce a stack trace. I tried digging into it further with break points but it got rather tricky.

It seems that on many occasions when CC calls into PAL’s thread manager it’s log of what the current thread should be is wrong which is what causes this.

[rhuanjl]

Noted that these "asserte"s only fire in a shared or dynamic build, static builds don't have this issue.