Application which uses many dlls crashes when using mimalloc under Windows

Hello,
our application crashes when it uses mimalloc-override.
The application uses many dlls.
The crash occurrs when memory within the CRT is freed.
Here ist the stacktrace:
ntdll.dll!string "Enabling heap debug options\n"()	Unbekannt
ntdll.dll!RtlValidateHeap()	Unbekannt
AcXtrnal.dll!000007febd077bac()	Unbekannt
ucrtbase.dll!__acrt_free_locale()	Unbekannt
ucrtbase.dll!_updatetlocinfoEx_nolock()	Unbekannt
ucrtbase.dll!_updatetlocinfoEx_nolock()	Unbekannt
ucrtbase.dll!__crt_seh_guarded_call<void>::operator()<class <lambda_d67e8342c384adda8f857579ab50b2ae>,class <lambda_30712929f77e709619002f448b6a9510> &,class <lambda_4525336fd7e478d965fb7ca7a337cad8> >(class <lambda_d67e8342c384adda8f857579ab50b2ae> &&,class <lambda_30712929f77e709619002f448b6a9510> &,class <lambda_4525336fd7e478d965fb7ca7a337cad8> &&)	Unbekannt
ucrtbase.dll!_wcscats()	Unbekannt
ucrtbase.dll!__crt_seh_guarded_call<void>::operator()<class <lambda_5df02c53a8f32f81fd64e5bbb78039f1>,class <lambda_2af78c5f5901b1372d98f9ab3177dfa6> &,class <lambda_f51fe5fd7c79a33db34fc9310f277369> &>(class <lambda_5df02c53a8f32f81fd64e5bbb78039f1> &&,class <lambda_2af78c5f5901b1372d98f9ab3177dfa6> &,class <lambda_f51fe5fd7c79a33db34fc9310f277369> &)	Unbekannt
ucrtbase.dll!_wsetlocale()	Unbekannt
ucrtbase.dll!___lc_locale_name_func()	Unbekannt
ucrtbase.dll!setlocale()	Unbekannt
msvcp140.dll!000007fee58c1724()	Unbekannt
msvcp140.dll!000007fee58b46a4()	Unbekannt
msvcp140.dll!000007fee58b5e59()	Unbekannt

dlltools.dll!std::use_facet<std::codecvt<char,char,_Mbstatet>>(const std::locale & _Loc) Zeile 519	C++
[Inlineframe] dlltools.dll!std::basic_filebuf<char,std::char_traits>::open(const char *) Zeile 292	C++
[Inlineframe] dlltools.dll!std::basic_fstream<char,std::char_traits>::{ctor}(const char *) Zeile 1328	C++
dlltools.dll!C_ConfigFile::CheckForNewLineOnLastLine() Zeile 904	C++
dlltools.dll!C_ConfigFile::SetLockName() Zeile 159	C++
dlltools.dll!C_ConfigFile::SetConfigFileName(const std::string & strName) Zeile 883	C++
dlltools.dll!C_ZISDirectories::ReadConfigFile() Zeile 785	C++
dlltools.dll!C_ZISDirectories::Init_Impl() Zeile 418	C++
dlltools.dll!C_ZISDirectories::C_ZISDirectories() Zeile 70	C++
dlltools.dll!C_ZISDirectories::instance(const char * pszBinDirectory) Zeile 57	C++
dllunittestutilities.dll!C_ConsoleModus::ActivateLocalMiniDump_Impl() Zeile 223	C++
dllunittestutilities.dll!C_ConsoleModus::Execute(int argc, char * * argv, const std::string & strXMLFileName) Zeile 53	C++
dbgtools.exe!ace_main_i(int argc, char * * argv) Zeile 347	C++
dbgtools.exe!main(int argc, char * * argv) Zeile 181	C++

This is the executed code in "dlltools.dll!C_ConfigFile::CheckForNewLineOnLastLine() Zeile 904":
std::fstream myFile(strConfigFileName.c_str(), std::ios::in | std::ios::out);
if(myFile.is_open())
...
The application crashes in "Debug" and in "Release" mode.
When the application starts in "Debug" mode the following message is printed to stdout:
"mimalloc-redirect: warning: unable to resolve "ucrtbase.DLL!_msize_base" -- this may cause allocation errors."
In the "Release" mode no message is printed to stdout.
The same code works fine when it is executed within the test application mimalloc-override-test.exe.
int main() {
//mi_stats_reset();  // ignore earlier allocations
atexit(free_p);
void* p1 = malloc(78);
void* p2 = mi_malloc_aligned(16,24);
free(p1);
p1 = malloc(8);
char* s = mi_strdup("hello\n");
_putenv("TEST=ENV");
int twice = 0;
do
{
printf("Locale is: %s\n", setlocale(LC_ALL, NULL));
std::fstream myfile("example.txt", std::ios::in | std::ios::out);
if(myfile.is_open())
{
myfile << "This is a line.\n";
myfile << "This is another line.\n";
myfile.close();
}
setlocale(LC_ALL, "");
}
while(!twice++);
...
}
Best regards
Michael

Ouch -- the error looks not good. I need a bit more information:

can you tell me exactly what Windows version you are running on?  If you know what the windows SDK version is (for the ucrtbase version) that would be great too. Do you compile for 64-bit?
can you set MI_VERBOSE=1 in release mode and see if you get any warnings?
or even MI_VERBOSE=3 to see very detailed info.

Also, make sure that the mimalloc-override.dll is first on the linker command line so it loads early (and thus mimalloc-redirect.dll loads early.)

can you tell me exactly what Windows version you are running on?
Windows 7 Ultimate Service Pack 1

if you know what the windows SDK version is (for the ucrtbase version) that would be great too.
In "Debug" mode ucrtbase.dll and ucrtbased.dll are loaded.
ucrtbase	  10.0.10586.788 (th2_release_sec.170113-1732)
ucrtbased  10.0.18362.1 (WinBuild.160101.0800)

Also, make sure that the mimalloc-override.dll is first on the linker command line so it loads early (and thus mimalloc-redirect.dll loads early.)
Now mimalloc-override.dll is loaded as 5th dll.
In "Debug" mode I can see the command line menu. But when a test in the application is executed the application crashes.
In "Release" mode the appliction crashes immediately after start.

I have appended 2 files.
They contain:

console output with MI_VERBOSE=3
stacktrace of the crash
order of the loaded modules (copy this to Excel and you can see a prettier output)

mimalloc_debug.txt
mimalloc_release.txt

I looked at the output and it is clearly the "_msize_base" that goes wrong :-(  I tried to replace my ucrtbase.dll with the one you used but was unable to do so on my machine -- windows seems to special tricks around system32 that makes this not easy to do; I will try again later. This would hopefully allow me to reproduce the error.
ps. If this doesn't work out we could perhaps set up a remote debug session -- I think I can figure it out when I see it.  If you are able to, perhaps you can set a breakpoint on "main"; when you hit it, then open a disassembly window and go to the address of ucrtbase.dll!_msize  (this address is also shown in the VERBOSE=3 output) and show me what it looks like (best with hex and assembly display).

Here is the result of result.
I hope I did it correctly.
mimalloc_release_output_hex.txt
mimalloc_debug_output_hex.txt

Hi @migra-leutek, that is great! It is almost what I need... (you used the addresses in mimalloc but I need the ones in ucrtbase :-))
Can you repeat just for the "release" version?  Use MIMALLOC_VERBOSE=3, and then break at main. Then open the disassembly window in the debugger and type in its address window: ucrtbase.DLL!_msize -- this should work. Then send me the first 10 or so assembly instructions (and hex codes) that you see.
Apologies for this kind of tricky-ness but I hope we can figure out what is going on.

This time it should be correct :-).
mimalloc_release_disassembly_with_hex_codes.txt

Thanks -- I am still not sure what is going on though; it looks to be ok. I will investigate further and let you know how it goes.

I created a test version of mimalloc-direct; can you copy it into your test (and overwrite the old one) and see how it goes?
Thanks!

Good job :-). Now it works without any crash!
mimalloc_release_console_output.txt

Hello Daan,
great job :-). Now it works without any crash!
Thanks
Michael
Von: Daan<EMAIL_ADDRESS>Gesendet: Freitag, 15. November 2019 05:55
An: microsoft/mimalloc<EMAIL_ADDRESS>Cc: Graf, Michael<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Betreff: Re: [microsoft/mimalloc] Application which uses many dlls crashes when using mimalloc under Windows (#170)
I created a test versionhttps://www.dropbox.com/s/1gwkrov8jqdb9ag/mimalloc-redirect.dll?dl=1 of mimalloc-direct; can you copy it into your test (and overwrite the old one) and see how it goes?
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/mimalloc/issues/170?email_source=notifications&email_token=AJKN6EYKGWWALLUL4WOKVLTQTYTTFA5CNFSM4JKVRTV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEEJV3I#issuecomment-554212077, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJKN6E6G5FFOYHUF2C7JLPDQTYTTFANCNFSM4JKVRTVQ.
mimalloc: option 'show_errors': 0
mimalloc: option 'show_stats': 0
mimalloc: option 'eager_commit': 1
mimalloc: option 'eager_region_commit': 0
mimalloc: option 'large_os_pages': 0
mimalloc: option 'reserve_huge_os_pages': 0
mimalloc: option 'segment_cache': 0
mimalloc: option 'page_reset': 0
mimalloc: option 'cache_reset': 0
mimalloc: option 'reset_decommits': 0
mimalloc: option 'eager_commit_delay': 0
mimalloc: option 'segment_reset': 0
mimalloc: option 'os_tag': 100
mimalloc: process init: 0x7fffffdc000
mimalloc-redirect: trace: checking for target mimalloc.dll
mimalloc-redirect: trace: checking for target mimalloc-override.dll
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dbgtools.exe"
mimalloc-redirect: trace: module "C:\Windows\SYSTEM32\ntdll.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\kernel32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\KERNELBASE.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\mimalloc-override.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\mimalloc-redirect.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ADVAPI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\msvcrt.dll"
mimalloc-redirect: trace: module "C:\Windows\SYSTEM32\sechost.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\RPCRT4.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\VCRUNTIME140.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-runtime-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ucrtbase.DLL"
mimalloc-redirect: trace: resolving "ucrtbase.DLL"
mimalloc-redirect: trace: resolve "malloc" at ucrtbase.DLL!0x000007FEF2E540F0 to mimalloc!0x000007FEEAA12800 (0)
mimalloc-redirect: trace: resolve "calloc" at ucrtbase.DLL!0x000007FEF2E54EF0 to mimalloc!0x000007FEEAA12160 (0)
mimalloc-redirect: trace: resolve "realloc" at ucrtbase.DLL!0x000007FEF2E466B0 to mimalloc!0x000007FEEAA12A10 (0)
mimalloc-redirect: trace: resolve "free" at ucrtbase.DLL!0x000007FEF2E54180 to mimalloc!0x000007FEEAA12210 (0)
mimalloc-redirect: trace: resolve "_expand" at ucrtbase.DLL!0x000007FEF2EA0460 to mimalloc!0x000007FEEAA121D0 (0)
mimalloc-redirect: trace: resolve "_recalloc" at ucrtbase.DLL!0x000007FEF2E42AE0 to mimalloc!0x000007FEEAA12B40 (0)
mimalloc-redirect: trace: resolve "_msize" at ucrtbase.DLL!0x000007FEF2E54140 to mimalloc!0x000007FEEAA12C60 (0)
mimalloc-redirect: trace: resolve "_malloc_base" at ucrtbase.DLL!0x000007FEF2E49120 to mimalloc!0x000007FEEAA12800 (0)
mimalloc-redirect: trace: resolve "_calloc_base" at ucrtbase.DLL!0x000007FEF2E4E160 to mimalloc!0x000007FEEAA12160 (0)
mimalloc-redirect: trace: resolve "_realloc_base" at ucrtbase.DLL!0x000007FEF2E47560 to mimalloc!0x000007FEEAA12A10 (0)
mimalloc-redirect: trace: resolve "_free_base" at ucrtbase.DLL!0x000007FEF2E4A890 to mimalloc!0x000007FEEAA12210 (0)
mimalloc-redirect: trace: resolve "_expand_base" at ucrtbase.DLL!0x000007FEF2EA046C to mimalloc!0x000007FEEA9F2650 (0)
mimalloc-redirect: trace: resolve "_recalloc_base" at ucrtbase.DLL!0x000007FEF2E474BC to mimalloc!0x000007FEEA9F2680 (0)
mimalloc-redirect: warning: unable to resolve "ucrtbase.DLL!_msize_base" -- enabling MIMALLOC_PATCH_IMPORTS to prevent allocation errors.
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlSizeHeap" in ucrtbase.DLL at 0x000007FEF2EEC200 to 0x000007FEEA9F2D70 (0)
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlFreeHeap" in ucrtbase.DLL at 0x000007FEF2EEC218 to 0x000007FEEA9F2DE0 (0)
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlReAllocateHeap" in ucrtbase.DLL at 0x000007FEF2EEC1D8 to 0x000007FEEA9F2E70 (0)
mimalloc-redirect: trace: resolve "_aligned_malloc" at ucrtbase.DLL!0x000007FEF2E9FFE0 to mimalloc!0x000007FEEAA11670 (0)
mimalloc-redirect: trace: resolve "_aligned_realloc" at ucrtbase.DLL!0x000007FEF2EA0430 to mimalloc!0x000007FEEAA116F0 (0)
mimalloc-redirect: trace: resolve "_aligned_free" at ucrtbase.DLL!0x000007FEF2E9FFB0 to mimalloc!0x000007FEEAA12210 (0)
mimalloc-redirect: trace: resolve "_aligned_recalloc" at ucrtbase.DLL!0x000007FEF2EA0440 to mimalloc!0x000007FEEAA11A10(0)
mimalloc-redirect: trace: resolve "_aligned_msize" at ucrtbase.DLL!0x000007FEF2E9FFF0 to mimalloc!0x000007FEEA9F2A60 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_malloc" at ucrtbase.DLL!0x000007FEF2EA0090 to mimalloc!0x000007FEEAA116B0 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_realloc" at ucrtbase.DLL!0x000007FEF2EA0160 to mimalloc!0x000007FEEAA11760 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_recalloc" at ucrtbase.DLL!0x000007FEF2EA0370 to mimalloc!0x000007FEEAA11A00 (0)
mimalloc-redirect: error: mimalloc-redirect.dll is initialized after ucrtbase.DLL -- redirection is disabled.
(try to link with mimalloc earlier on the command line?)
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-timezone-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-file-l2-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-localization-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-synch-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-processthreads-l1-1-1.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-file-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-heap-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-string-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-stdio-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-convert-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-environment-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-conio-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\cppunit\lib\cppunit_dll.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\MSVCP140.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-locale-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-filesystem-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-time-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-math-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-utility-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\ACE_wrappers\lib\ACE.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\IPHLPAPI.DLL"
mimalloc-redirect: trace: module "C:\Windows\system32\NSI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WINNSI.DLL"
mimalloc-redirect: trace: module "C:\Windows\system32\USER32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\GDI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\LPK.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\USP10.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WS2_32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\MSWSOCK.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\NETAPI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\netutils.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\srvcli.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\wkscli.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WINMM.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\zlib\lib\zlib1.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icuin60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icuuc60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icudt60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dll7zhelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltools.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\SHELL32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\SHLWAPI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ole32.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllmemorymanager.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\DNSAPI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\VERSION.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-multibyte-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllarchivehelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\libarchive\lib\archive.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\bzip2\lib\LIBBZ2.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\bcrypt.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllbzip2helper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllcron4cpp.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlldatetime.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllgziphelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllmemoryleakdetector.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltesta.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltestb.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllunittestutilities.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\ltutils.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllcurlutil.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\ACE_wrappers\lib\ACE_SSL.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\openssl\out32dll\SSLEAY32.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\openssl\out32dll\LIBEAY32.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\curl\lib\libcurl.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\libssh2\lib\libssh2.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\apphelp.dll"

I just have seen this message:

(try to link with mimalloc earlier on the command line?)
The 'Module' window in the debugger says
mimalloc_release_module_load_ranking.txt
that mimalloc is loaded as 5th and 6th module.

Hi @migra-leutek,
The good news is that I think my fix works ... but the bad news is that in your test mimalloc is currently not enabled:
mimalloc-redirect: error: mimalloc-redirect.dll is initialized after ucrtbase.DLL -- redirection is disabled.
  (try to link with mimalloc earlier on the command line?)

If mimalloc-redirect loads too late (after ucrtbase) it disables itself as it is not guaranteed to be robust in that case. The way to get it to load earlier is to put mimalloc-override.lib more early on the linker command line.  You can check where it ended up in the import tables using dumpbin /IMPORTS <myexe> and see how early it is (usually after kernel32 but before vcruntime140)
Let me know how it goes.
(ps. if that fails or is difficult to do, you can also use CFF Explorer to open the exe and go to
the import directory and right-click on the mimalloc-override entry and move it up until it is first. I might automate this but in practice adjusting the linker command line has always worked)

Hi @daanx,
The output of mimalloc is still:
mimalloc-redirect: error: mimalloc-redirect.dll is initialized after ucrtbase.DLL -- redirection is disabled.
(try to link with mimalloc earlier on the command line?)
although I think mimalloc-override.lib should be the first module which will be loaded by dbgtools.exe.
Here is the linker command line:
dbgtools.exe_linker_command_line.txt
Here is module output of the debugger:

Here is what the COFF Explorer outputs:

Here is the output of "dumpbin /IMPORTS dbgtools.exe":
dbgtools.exe_dumpbin_imports.txt
Here is the console output of dbgtools.exe:
dbgtools.exe_console_output.txt
What I am doing wrong ?

Ah, not sure -- the output all looks good; (Sorry for the trouble but it is really helpful as I cannot repro this behaviour myself).
Can you try one more thing? With CFF Explorer edit the exe: go to "Import Adder" and add "mimalloc-redirect.dll" explicitly (just import any function from it) and move it all the way up to be the first.
Another cause could be that the check I am doing if ucrtbase is not yet initialized is going wrong; I will provide another build of mimalloc-redirect to ignore the error and keep running; perhaps everything is actually working :-)

The message

(try to link with 'mimalloc-override.lib' earlier on the command line?)
is shown in all cases.

Here are the results:

dbgtools.exe_dumpbin_imports.txt
dbgtools.exe_console_output_with_new_mimalloc-redirect.dll_as_first_module_in_import_table_and_environment_variable_MIMALLOC_FORCE_REDIRECT_is_0.txt
dbgtools.exe_console_output_with_new_mimalloc-redirect.dll_as_first_module_in_import_table_and_environment_variable_MIMALLOC_FORCE_REDIRECT_is_1.txt

Ah, with the new mimalloc-redirect and MIMALLOC_FORCE_DIRECT=1, it is actually working despite the error message (since it does say mimalloc: malloc is redirected. somewhere). So, if you add MIMALLOC_SHOW_STATS=1  (or MI_VERBOSE=1) you should see after running that it mimalloc allocated things.  Also, it does seem it is no longer crashing?

Hello Daan,

So, if you add MIMALLOC_SHOW_STATS=1 (or MI_VERBOSE=1) you should see after running that it mimalloc allocated things.
Yes, mimalloc is active despite the error message.

Also, it does seem it is no longer crashing?
A crash doesn’t occur any longer.

Thanks
Michael
Von: Daan<EMAIL_ADDRESS>Gesendet: Dienstag, 19. November 2019 07:07
An: microsoft/mimalloc<EMAIL_ADDRESS>Cc: Graf, Michael<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Betreff: Re: [microsoft/mimalloc] Application which uses many dlls crashes when using mimalloc under Windows (#170)
Ah, with the new mimalloc-redirect and MIMALLOC_FORCE_DIRECT=1, it is actually working despite the error message (since it does say mimalloc: malloc is redirected. somewhere). So, if you add MIMALLOC_SHOW_STATS=1 (or MI_VERBOSE=1) you should see after running that it mimalloc allocated things. Also, it does seem it is no longer crashing?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/mimalloc/issues/170?email_source=notifications&email_token=AJKN6EY4AKCBKUIULBF5SKTQUN7ATA5CNFSM4JKVRTV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEM7G6Q#issuecomment-555348858, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJKN6E4OQG623KH5ERIMISDQUN7ATANCNFSM4JKVRTVQ.

That is great to hear! I will adjust the message and I at least know what is going on. Still need to work on a better initialization detection... if you are willing, I will send more test builds your way to try out?
Hope mimalloc improves performance for your workloads, thanks for helping to fix these errors!

if you are willing, I will send more test builds your way to try out?
That’s ok.

Von: Daan<EMAIL_ADDRESS>Gesendet: Dienstag, 19. November 2019 20:50
An: microsoft/mimalloc<EMAIL_ADDRESS>Cc: Graf, Michael<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Betreff: Re: [microsoft/mimalloc] Application which uses many dlls crashes when using mimalloc under Windows (#170)
That is great to hear! I will adjust the message and I at least know what is going on. Still need to work on a better initialization detection... if you are willing, I will send more test builds your way to try out?
Hope mimalloc improves performance for your workloads, thanks for helping to fix these errors!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/mimalloc/issues/170?email_source=notifications&email_token=AJKN6EZIKI53NMYOP4X6N2LQUQ7N5A5CNFSM4JKVRTV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEPQDCA#issuecomment-555680136, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJKN6EZLQAR5GOLHRAXA44TQUQ7N5ANCNFSM4JKVRTVQ.

Hi, I created a new redirect dll with hopefully better initialization detection and messages. Can you try it with MIMALLOC_VERBOSE=3 and send the output? (Maybe with MIMALLOC_FORCE_REDIRECT=1 as well in case initialization detection still fails)  Thanks!

Hi Daan,
here are the outputs.
Michael
Von: Daan<EMAIL_ADDRESS>Gesendet: Freitag, 22. November 2019 00:32
An: microsoft/mimalloc<EMAIL_ADDRESS>Cc: Graf, Michael<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Betreff: Re: [microsoft/mimalloc] Application which uses many dlls crashes when using mimalloc under Windows (#170)
Hi, I created a new redirect dllhttps://www.dropbox.com/s/1gwkrov8jqdb9ag/mimalloc-redirect.dll?dl=1 with hopefully better initialization detection and messages. Can you try it with MIMALLOC_VERBOSE=3 and send the output? (Maybe with MIMALLOC_FORCE_REDIRECT=1 as well in case initialization detection still fails) Thanks!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/mimalloc/issues/170?email_source=notifications&email_token=AJKN6E44ZRKQ7UP74XZLSNLQU4K5LA5CNFSM4JKVRTV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE4AMGQ#issuecomment-557319706, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJKN6E2RHQUQCM7D4M4G2RLQU4K5LANCNFSM4JKVRTVQ.
e:\cvs_5825_x64\stage\B5825\x64\Release\bin>set MI
MIMALLOC_FORCE_REDIRECT=0
MIMALLOC_SHOW_ERRORS=1
MIMALLOC_SHOW_STATS=1
MIMALLOC_VERBOSE=3
e:\cvs_5825_x64\stage\B5825\x64\Release\bin>dbgtools.exe
mimalloc: option 'show_errors': 1
mimalloc: option 'show_stats': 1
mimalloc: option 'eager_commit': 1
mimalloc: option 'eager_region_commit': 0
mimalloc: option 'large_os_pages': 0
mimalloc: option 'reserve_huge_os_pages': 0
mimalloc: option 'segment_cache': 0
mimalloc: option 'page_reset': 0
mimalloc: option 'cache_reset': 0
mimalloc: option 'reset_decommits': 0
mimalloc: option 'eager_commit_delay': 0
mimalloc: option 'segment_reset': 0
mimalloc: option 'os_tag': 100
mimalloc: malloc is redirected.
mimalloc-redirect: trace: build: Nov 20 2019
mimalloc-redirect: trace: checking for target mimalloc.dll
mimalloc-redirect: trace: checking for target mimalloc-override.dll
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dbgtools.exe"
mimalloc-redirect: trace: module "C:\Windows\SYSTEM32\ntdll.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\kernel32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\KERNELBASE.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\mimalloc-override.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\mimalloc-redirect.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ADVAPI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\msvcrt.dll"
mimalloc-redirect: trace: module "C:\Windows\SYSTEM32\sechost.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\RPCRT4.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\VCRUNTIME140.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-runtime-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ucrtbase.DLL"
mimalloc-redirect: trace: resolving "ucrtbase.DLL"
mimalloc-redirect: trace: resolve "malloc" at ucrtbase.DLL!0x000007FEE36440F0 to mimalloc!0x000007FED65F2800 (0)
mimalloc-redirect: trace: resolve "calloc" at ucrtbase.DLL!0x000007FEE3644EF0 to mimalloc!0x000007FED65F2160 (0)
mimalloc-redirect: trace: resolve "realloc" at ucrtbase.DLL!0x000007FEE36366B0 to mimalloc!0x000007FED65F2A10 (0)
mimalloc-redirect: trace: resolve "free" at ucrtbase.DLL!0x000007FEE3644180 to mimalloc!0x000007FED65F2210 (0)
mimalloc-redirect: trace: resolve "_expand" at ucrtbase.DLL!0x000007FEE3690460 to mimalloc!0x000007FED65F21D0 (0)
mimalloc-redirect: trace: resolve "_recalloc" at ucrtbase.DLL!0x000007FEE3632AE0 to mimalloc!0x000007FED65F2B40 (0)
mimalloc-redirect: trace: resolve "_msize" at ucrtbase.DLL!0x000007FEE3644140 to mimalloc!0x000007FED65F2C60 (0)
mimalloc-redirect: trace: resolve "_malloc_base" at ucrtbase.DLL!0x000007FEE3639120 to mimalloc!0x000007FED65F2800 (0)
mimalloc-redirect: trace: resolve "_calloc_base" at ucrtbase.DLL!0x000007FEE363E160 to mimalloc!0x000007FED65F2160 (0)
mimalloc-redirect: trace: resolve "_realloc_base" at ucrtbase.DLL!0x000007FEE3637560 to mimalloc!0x000007FED65F2A10 (0)
mimalloc-redirect: trace: resolve "_free_base" at ucrtbase.DLL!0x000007FEE363A890 to mimalloc!0x000007FED65F2210 (0)
mimalloc-redirect: trace: resolve "_expand_base" at ucrtbase.DLL!0x000007FEE369046C to mimalloc!0x000007FED40D4D80 (0)
mimalloc-redirect: trace: resolve "_recalloc_base" at ucrtbase.DLL!0x000007FEE36374BC to mimalloc!0x000007FED40D4DB0 (0)
mimalloc-redirect: warning: unable to resolve "ucrtbase.DLL!_msize_base" -- enabling MIMALLOC_PATCH_IMPORTS to prevent allocation errors.
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlSizeHeap" in ucrtbase.DLL at 0x000007FEE36DC200 to 0x000007FED40D54A0 (0)
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlFreeHeap" in ucrtbase.DLL at 0x000007FEE36DC218 to 0x000007FED40D5510 (0)
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlReAllocateHeap" in ucrtbase.DLL at 0x000007FEE36DC1D8 to 0x000007FED40D55A0 (0)
mimalloc-redirect: trace: resolve "_aligned_malloc" at ucrtbase.DLL!0x000007FEE368FFE0 to mimalloc!0x000007FED65F1670 (0)
mimalloc-redirect: trace: resolve "_aligned_realloc" at ucrtbase.DLL!0x000007FEE3690430 to mimalloc!0x000007FED65F16F0 (0)
mimalloc-redirect: trace: resolve "_aligned_free" at ucrtbase.DLL!0x000007FEE368FFB0 to mimalloc!0x000007FED65F2210 (0)
mimalloc-redirect: trace: resolve "_aligned_recalloc" at ucrtbase.DLL!0x000007FEE3690440 to mimalloc!0x000007FED65F1A10 (0)
mimalloc-redirect: trace: resolve "_aligned_msize" at ucrtbase.DLL!0x000007FEE368FFF0 to mimalloc!0x000007FED40D5190 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_malloc" at ucrtbase.DLL!0x000007FEE3690090 to mimalloc!0x000007FED65F16B0 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_realloc" at ucrtbase.DLL!0x000007FEE3690160 to mimalloc!0x000007FED65F1760 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_recalloc" at ucrtbase.DLL!0x000007FEE3690370 to mimalloc!0x000007FED65F1A00 (0)
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-timezone-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-file-l2-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-localization-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-synch-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-processthreads-l1-1-1.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-file-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-heap-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-string-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-stdio-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-convert-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-environment-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-conio-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\cppunit\lib\cppunit_dll.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\MSVCP140.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-locale-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-filesystem-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-time-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-math-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-utility-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\ACE_wrappers\lib\ACE.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\IPHLPAPI.DLL"
mimalloc-redirect: trace: module "C:\Windows\system32\NSI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WINNSI.DLL"
mimalloc-redirect: trace: module "C:\Windows\system32\USER32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\GDI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\LPK.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\USP10.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WS2_32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\MSWSOCK.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\NETAPI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\netutils.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\srvcli.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\wkscli.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WINMM.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\zlib\lib\zlib1.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icuin60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icuuc60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icudt60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dll7zhelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltools.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\SHELL32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\SHLWAPI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ole32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\DNSAPI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\VERSION.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-multibyte-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllarchivehelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\libarchive\lib\archive.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\bzip2\lib\LIBBZ2.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\bcrypt.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllbzip2helper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllcron4cpp.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlldatetime.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllgziphelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllmemoryleakdetector.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllmemorymanager.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltesta.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltestb.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllunittestutilities.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\ltutils.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllcurlutil.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\ACE_wrappers\lib\ACE_SSL.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\openssl\out32dll\SSLEAY32.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\openssl\out32dll\LIBEAY32.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\curl\lib\libcurl.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\libssh2\lib\libssh2.dll"
mimalloc-redirect: trace: standard malloc is redirected
Execute tests or list tests/test methods
Usage:
dbgtools.exe
-e(xecuteTest)
or
-e(xecuteTest) all
or
-l(istAllTests)
or
-listAllTestMethods
e.g.  dbgtools.exe  -e C_ToolsTestCase
dbgtools.exe  -e C_ToolsTestCase::Test_IsNumeric
dbgtools.exe  -e all
dbgtools.exe  -listAllTests
dbgtools.exe  -listAllTestMethods C_ToolsTestCase
Please press 'x' to finish program ...
e:\cvs_5825_x64\stage\B5825\x64\Release\bin>
e:\cvs_5825_x64\stage\B5825\x64\Release\bin>set MI
MIMALLOC_FORCE_REDIRECT=1
MIMALLOC_SHOW_ERRORS=1
MIMALLOC_SHOW_STATS=1
MIMALLOC_VERBOSE=3
e:\cvs_5825_x64\stage\B5825\x64\Release\bin>dbgtools.exe
mimalloc: option 'show_errors': 1
mimalloc: option 'show_stats': 1
mimalloc: option 'eager_commit': 1
mimalloc: option 'eager_region_commit': 0
mimalloc: option 'large_os_pages': 0
mimalloc: option 'reserve_huge_os_pages': 0
mimalloc: option 'segment_cache': 0
mimalloc: option 'page_reset': 0
mimalloc: option 'cache_reset': 0
mimalloc: option 'reset_decommits': 0
mimalloc: option 'eager_commit_delay': 0
mimalloc: option 'segment_reset': 0
mimalloc: option 'os_tag': 100
mimalloc: malloc is redirected.
mimalloc-redirect: trace: build: Nov 20 2019
mimalloc-redirect: trace: checking for target mimalloc.dll
mimalloc-redirect: trace: checking for target mimalloc-override.dll
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dbgtools.exe"
mimalloc-redirect: trace: module "C:\Windows\SYSTEM32\ntdll.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\kernel32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\KERNELBASE.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\mimalloc-override.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\mimalloc-redirect.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ADVAPI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\msvcrt.dll"
mimalloc-redirect: trace: module "C:\Windows\SYSTEM32\sechost.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\RPCRT4.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\VCRUNTIME140.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-runtime-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ucrtbase.DLL"
mimalloc-redirect: trace: resolving "ucrtbase.DLL"
mimalloc-redirect: trace: resolve "malloc" at ucrtbase.DLL!0x000007FEE36440F0 to mimalloc!0x000007FED4012800 (0)
mimalloc-redirect: trace: resolve "calloc" at ucrtbase.DLL!0x000007FEE3644EF0 to mimalloc!0x000007FED4012160 (0)
mimalloc-redirect: trace: resolve "realloc" at ucrtbase.DLL!0x000007FEE36366B0 to mimalloc!0x000007FED4012A10 (0)
mimalloc-redirect: trace: resolve "free" at ucrtbase.DLL!0x000007FEE3644180 to mimalloc!0x000007FED4012210 (0)
mimalloc-redirect: trace: resolve "_expand" at ucrtbase.DLL!0x000007FEE3690460 to mimalloc!0x000007FED40121D0 (0)
mimalloc-redirect: trace: resolve "_recalloc" at ucrtbase.DLL!0x000007FEE3632AE0 to mimalloc!0x000007FED4012B40 (0)
mimalloc-redirect: trace: resolve "_msize" at ucrtbase.DLL!0x000007FEE3644140 to mimalloc!0x000007FED4012C60 (0)
mimalloc-redirect: trace: resolve "_malloc_base" at ucrtbase.DLL!0x000007FEE3639120 to mimalloc!0x000007FED4012800 (0)
mimalloc-redirect: trace: resolve "_calloc_base" at ucrtbase.DLL!0x000007FEE363E160 to mimalloc!0x000007FED4012160 (0)
mimalloc-redirect: trace: resolve "_realloc_base" at ucrtbase.DLL!0x000007FEE3637560 to mimalloc!0x000007FED4012A10 (0)
mimalloc-redirect: trace: resolve "_free_base" at ucrtbase.DLL!0x000007FEE363A890 to mimalloc!0x000007FED4012210 (0)
mimalloc-redirect: trace: resolve "_expand_base" at ucrtbase.DLL!0x000007FEE369046C to mimalloc!0x000007FED65F4D80 (0)
mimalloc-redirect: trace: resolve "_recalloc_base" at ucrtbase.DLL!0x000007FEE36374BC to mimalloc!0x000007FED65F4DB0 (0)
mimalloc-redirect: warning: unable to resolve "ucrtbase.DLL!_msize_base" -- enabling MIMALLOC_PATCH_IMPORTS to prevent allocation errors.
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlSizeHeap" in ucrtbase.DLL at 0x000007FEE36DC200 to 0x000007FED65F54A0 (0)
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlFreeHeap" in ucrtbase.DLL at 0x000007FEE36DC218 to 0x000007FED65F5510 (0)
mimalloc-redirect: trace: resolve import "ntdll.dll!RtlReAllocateHeap" in ucrtbase.DLL at 0x000007FEE36DC1D8 to 0x000007FED65F55A0 (0)
mimalloc-redirect: trace: resolve "_aligned_malloc" at ucrtbase.DLL!0x000007FEE368FFE0 to mimalloc!0x000007FED4011670 (0)
mimalloc-redirect: trace: resolve "_aligned_realloc" at ucrtbase.DLL!0x000007FEE3690430 to mimalloc!0x000007FED40116F0 (0)
mimalloc-redirect: trace: resolve "_aligned_free" at ucrtbase.DLL!0x000007FEE368FFB0 to mimalloc!0x000007FED4012210 (0)
mimalloc-redirect: trace: resolve "_aligned_recalloc" at ucrtbase.DLL!0x000007FEE3690440 to mimalloc!0x000007FED4011A10 (0)
mimalloc-redirect: trace: resolve "_aligned_msize" at ucrtbase.DLL!0x000007FEE368FFF0 to mimalloc!0x000007FED65F5190 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_malloc" at ucrtbase.DLL!0x000007FEE3690090 to mimalloc!0x000007FED40116B0 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_realloc" at ucrtbase.DLL!0x000007FEE3690160 to mimalloc!0x000007FED4011760 (0)
mimalloc-redirect: trace: resolve "_aligned_offset_recalloc" at ucrtbase.DLL!0x000007FEE3690370 to mimalloc!0x000007FED4011A00 (0)
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-timezone-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-file-l2-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-localization-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-synch-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-processthreads-l1-1-1.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-core-file-l1-2-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-heap-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-string-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-stdio-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-convert-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-environment-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-conio-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\cppunit\lib\cppunit_dll.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\MSVCP140.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-locale-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-filesystem-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-time-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-math-l1-1-0.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-utility-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\ACE_wrappers\lib\ACE.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\IPHLPAPI.DLL"
mimalloc-redirect: trace: module "C:\Windows\system32\NSI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WINNSI.DLL"
mimalloc-redirect: trace: module "C:\Windows\system32\USER32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\GDI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\LPK.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\USP10.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WS2_32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\MSWSOCK.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\NETAPI32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\netutils.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\srvcli.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\wkscli.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\WINMM.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\zlib\lib\zlib1.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icuin60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icuuc60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\icu\bin\icudt60.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dll7zhelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltools.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\SHELL32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\SHLWAPI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\ole32.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\DNSAPI.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\VERSION.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\api-ms-win-crt-multibyte-l1-1-0.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllarchivehelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\libarchive\lib\archive.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\bzip2\lib\LIBBZ2.dll"
mimalloc-redirect: trace: module "C:\Windows\system32\bcrypt.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllbzip2helper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllcron4cpp.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlldatetime.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllgziphelper.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllmemoryleakdetector.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllmemorymanager.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltesta.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dlltestb.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllunittestutilities.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\ltutils.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\stage\B5825\x64\Release\bin\dllcurlutil.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\ACE_wrappers\lib\ACE_SSL.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\openssl\out32dll\SSLEAY32.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\openssl\out32dll\LIBEAY32.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\curl\lib\libcurl.dll"
mimalloc-redirect: trace: module "e:\cvs_5825_x64\all\vendor\libssh2\lib\libssh2.dll"
mimalloc-redirect: warning: there were errors during patching but these are ignored (due to MIMALLOC_FORCE_REDIRECT=1).
mimalloc-redirect: trace: standard malloc is redirected
Execute tests or list tests/test methods
Usage:
dbgtools.exe
-e(xecuteTest)
or
-e(xecuteTest) all
or
-l(istAllTests)
or
-listAllTestMethods
e.g.  dbgtools.exe  -e C_ToolsTestCase
dbgtools.exe  -e C_ToolsTestCase::Test_IsNumeric
dbgtools.exe  -e all
dbgtools.exe  -listAllTests
dbgtools.exe  -listAllTestMethods C_ToolsTestCase
Please press 'x' to finish program ...
e:\cvs_5825_x64\stage\B5825\x64\Release\bin>


Display download of images in build log

the build log is empty for several minutes.
reason is that the image gets downloaded for the first time:
928b8f4c06ba: Pulling metadata
928b8f4c06ba: Pulling fs layer
928b8f4c06ba: Download complete

the user should to know that, like with downloading image...

The 0.4 release writes to the log when pulling an image instead of displaying a completely blank screen for minutes. Hopefully that is enough, but if not we can revisit.


Boot member errors with "failed to find member" after pivot

I'm running into problems using the BootMemberClientEndpoint field. Before the operator is created, I have an etcd member running as a static pod using hostNetwork=true. These are its args:
--listen-peer-urls=http://<IP_ADDRESS>:12380
--advertise-client-urls=http://<IP_ADDRESS>:12379
--initial-cluster-state=new
--initial-advertise-peer-urls=http://<IP_ADDRESS>:12380
--listen-client-urls=http://<IP_ADDRESS>:12379
--initial-cluster=bootstrap=http://<IP_ADDRESS>:12380
--name=bootstrap
--data-dir=/var/lib/etcd

I then deploy the operator (also hostNetwork=true), and send this EtcdCluster spec:
ClusterSpec{
     Size:    3,
     Version: v3.1.8,
     SelfHosted: SelfHostedPolicy{
          BootMemberClientEndpoint: "http://localhost:12379",
          SkipBootMemberRemoval:    true,
     }
     // snip PodPolicy
}

The EtcdCluster is created successfully into a pod called etcd-cluster-0000. However, the bootstrap etcd starts to error:
rafthttp: failed to find member 55a39bcb338a9147 in cluster a7ef944b95711739

For some reason it can't locate the new self-hosted member (ID 55a39bcb338a9147).
Looking at the relevant source code in etcd, it says this might happen for two reasons:

user starts a remote peer that belongs to a different cluster with the same cluster ID.
local etcd falls behind of the cluster, and cannot recognize the members that joined after its current progress.

I don't think it's 1 because the operator uses --init-cluster=existing. How would the bootstrap "fall behind of the cluster"?
Operator logs here
Boot etcd logs here
self-hosted etcd logs here

This was my fault - I forgot to delete /var/etcd after kubeadm reset 🤦♂


UART wrong bound rate

It looks that at bound rate=9600 the timer sends data with the speed of ~888. And then computer can't understand the output.

I think I just got bitten by this bug: https://arduino.stackexchange.com/q/47297/1568
However, I am confused by your comment. Do you mean that setting the rate to 9600 baud results in an effective rate of 888 baud? Doesn't that mean I should be able to get good output by setting the baud rate to  103783?
Because I've just now tried that, and I am now only getting garbage out, whereas when using the nominal baud rate of 9600, I am at least getting some bits (the lower nybble) right.


Security Through Obscurity: Exposed PAT

The example has a security flaw: the PAT located at ${AZP_TOKEN_FILE} is accessible from builds/releases run on these agents (even though the path is "masked" from pipelines by unsetting the envvar... the file is there and can be manipulated by pipelines) - this is especially dangerous because there's a default file... people with bad intentions can run cat /azp/.token and likely have manage rights to the pool the agent is in. Yikes.
Any ideas on how to resolve this? Let's chat it out :)

Why are administrative tokens written to files accessible by pipelines?
Why, by default, are jobs run on the agent executed as root and not some other unprivileged user?

I feel like setting up and installing the agent can happen as root, but that final line should exec as a different user, but I don't know what kinds of privileges ./bin/AgentService.js requires or what it does, I see no docs for that...
Thank you!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b31d4f6c-d16d-2ba1-1294-6aa94e328046
Version Independent ID: 88aec599-4410-697d-1002-1c41b1c17bb6
Content: Running a self-hosted agent in Docker - Azure Pipelines
Content Source: docs/pipelines/agents/docker.md
Product: devops
Technology: devops-cicd
GitHub Login: @juliobbv
Microsoft Alias: juliobv

So, I burned some time on this... appears that proper user setup bypasses this flaw. I would post my updated file, but I've refactored it so heavily with custom logic it doesn't even resemble the base anymore... Here's the logic you need to patch this security flaw and prevent your agents from accessing the admin PAT or running root tasks in pipelines:

Dockerfile edits:

Create a new user with a RUN command (below refered to as ${USER})

Note that for docker (-in-docker) support, you'll need to set up some group memberships to access the /var/run/docker.sock socket...

while it might seem odd, run start.sh as ROOT (we still need to install the agent and chown/chmod stuff)

start.sh edits:

run a chmod 600 "${AZP_TOKEN_FILE}" after that file's creation
add a chown -R ${USER} /azp/agent command before running the agent (note that this will exclude /azp/.token -- for obvious reasons, ensure you don't set ${AZP_TOKEN_FILE} to some path starting with /azp/agent)
change the last line (line that runs the agent) to su - ${USER} -c "exec /azp/agent/externals/node10/bin/node /azp/agent/bin/AgentService.js interactive" (full paths!!)
aside from this, ensure all the tools you're installing alongside this base image can be accessed and executed by ${USER}... this might include running installers AS ${USER} (things like NVM/NPM, etc)

Hope this helps other teams.
As an aside... I really wish MSFT would just own this code as an official docker image so users could share a common and secure base image and just issue a docker pull to fix; instead, hundreds (thousands?) of admins will have to modify their own custom agents if they want this security patch... the next security patch that inevitably arises will have the same problem as this one. It's a tragedy that microsoft/azdo-agent suddenly fell out of flavor with over 10 million pulls - you left your customers in a pretty bad way with that choice.

@SudoBrendan - If ${AZURE_TOKEN_FILE} should be immutable, chmod 400 (or chmod 440 if it needs to be read by the root group) might be a better option.

Good call. Confirmed this. Use 400!

What about a simple rm filename after the pipeline agent got configured?

That might work - I figured that considering how much effort went into ensuring that file's existence in the script, the agent needed it there; definitely worth testing! I do know that the agent has some callbacks to AzDo during it's lifetime; re-establishing connections, unregistering itself, etc... maybe it loads the token into memory at some point? Maybe not?

Hi @SudoBrendan,
you got some good points.
I started a new project when the microsoft/azdo-agent was deprecated here:
https://github.com/codez-one/docker-azure-pipelines-agent
I think the same about the absense of a maintained Image for this use case. It is not at the same level as the old Microsoft repo but I think it is a good start.
Deleating the token can become a bit tricky because you might not be able to unregister the agent anymore.
It would be nice if you can help me to implement the user isolation into this project

Thanks for your question. It looks like your question isn't an issue with the documentation, but an issue or question specific to your implementation or a bug in the product itself.
For help with a specific task, here are a couple of options where you might consider asking your question:

Azure DevOps on Stack Overflow
Azure DevOps Support Bot

If you've encountered an issue with the product itself, to make sure it gets in front of the right people, please submit your bug here.
If you have an idea for improving the product, please submit your idea here.


Update cvmfs_info function

Address issue #574
Extend the use of cvmfs_info function to osgstorage repos alongside opensciencegrid repos
For SBND and ICARUS check also SBN CVMFS repos

This is a good idea ; should we also, for suitable experiments, be checking larsoft.opensciencegrid.org as well?

This is a good idea ; should we also, for suitable experiments, be checking larsoft.opensciencegrid.org as well?

I thought of this, but because for larsoft CVMFS repo we don't have the osgstorage repo I left this over.
However adding an extra check to exclude osgstorage, we can test also larsoft for suitable experiments.

I have included the check of larsoft CVMFS repo as suggested by Marc, alongside few other improvements.

@marcmengel I'll hold off on merging for a couple of days in case you wanted to check Vito's latest commit.


Cloud Optimized Data access example

@spa0002 see https://github.com/MAAP-Project/maap-documentation/tree/add/cloudopt_srtm branch for a draft notebook that uses SRTM data from MAAP data store, via the MAAP CMR api search. The slippy map visual is still being researched so maybe we'll leave that out of the first version.

There's a bug, that requires a newer rasterio version than what's in the Base image.
And a 2nd bug that makes using conda to upgrade break (might be fixed in OPS).
So make sure to use %pip install geopandas rasterio>=1.2.3 rio-cogeo


focusVisible is missing from AutocompleteClasses

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
Description:
When attempting to utilize the focusVisible property from the autocompleteClasses exported from '@mui/material/Autocomplete', I encountered a TypeScript error:
Property 'focusVisible' does not exist on type 'AutocompleteClasses'.ts

Steps to Reproduce:

Import the autocompleteClasses module from '@mui/material/Autocomplete'.
Attempt to use the focusVisible property from the AutocompleteClasses type.
Observe the TypeScript error mentioned above.

Current behavior 😯
Upon inspecting the AutocompleteClasses type in the material-ui\packages\mui-material\src\Autocomplete\autocompleteClasses.ts file, it appears that the 'focusVisible' property is missing.
Expected behavior 🤔
The focusVisible property should be accessible within the AutocompleteClasses type.
Context 🔦
No response
Your environment 🌎
No response

I'm seeing that in the file autocompleteClasses.ts the 'focusVisible' property does exist as part of the generateUtilityClasses function call here but it is missing from the exported AutocompleteClasses interface above. Would that be the cause? If it is I'm happy to raise a PR to add the property together with a short description.


Fixed workflow APIs not working in master branch

Fixes a regression introduced in a recent PR that converted the workflows APIs to universal. The map of workflow components was not set, so HTTP and gRPC APIs would not work.

We probably need to enable some E2E tests for Workflows APIs as errors like these should have been caught in E2E tests.

/ok-to-test

Fixes a regression introduced in a recent PR that converted the workflows APIs to universal. The map of workflow components was not set, so HTTP and gRPC APIs would not work.

Can you link to the PR that introduced the regression please?

We probably need to enable some E2E tests for Workflows APIs as errors like these should have been caught in E2E tests.

cc @cgillum @RyanLettieri


Disallow repeat form submission if AJAX submission is pending

Acceptance criteria

When you double click or click twice in rapid succession on the form save in campaign admin and asset editor, the form should only be submitted once.

Optional items / technical notes

Ideally, we'd find a generic solution for this which can apply to all forms (e.g. through FormBuilder).
Might have some overlap with the redux-forms work at https://github.com/silverstripe/silverstripe-framework/issues/5524
Disabling the button after it's clicked is one approach to do this. We'd want to be careful that this doesn't block people from intentionally submitting a 2nd time if they need to (e.g. if it appears to have hung), but I'm not sure how much of a concern this is.

I'd suggest disabling the button on submit? I'm reframing this issue as a specific problem in the 2 places mentioned with a recommendation to make a generic solution if possible.

Disabling the button after it's clicked is one approach to do this. We'd want to be careful that this doesn't block people from intentionally submitting a 2nd time if they need to (e.g. if it appears to have hung), but I'm not sure how much of a concern this is.

We can probably simply flag this behaviour on a per-action behaviour, perhaps by making it on by default?

Will disabling the button stop people hitting enter twice?

I think if you disable the default button, it disables the form too.

I'd probably just put a disabled state on the form that the handler looks for and doesn't send the request if it's present. More likely to solve any cross browser issues

This has been fixed, or at least I haven't been able to reproduce the issue with rapid clicks on the save buttons in the asset or campaign sections.


HTTPCLIENT-1944: Add hardCancellationEnabled option to RequestConfig

You can merge it as-is. Changing the default behavior may in turn require test code changes, so I'll send you a follow-up PR for that.


Fix export grater 10000

to fix this error:
Skipping virtualenv creation, as specified in config file. This is the format presigned_url Traceback (most recent call last):   File "/pelican/job_export.py", line 54, in <module> fallback to /download endpoint     case_ids = gql.execute(filters=filters)   File "/pelican/pelican/graphql/guppy_gql.py", line 70, in execute     self._download_endpoint(filters)   File "/pelican/pelican/graphql/guppy_gql.py", line 34, in _download_endpoint     r = BaseGQL._execute(self, query)   File "/pelican/pelican/graphql/base_gql.py", line 18, in _execute     var = query["variables"] KeyError: 'variables'


Hey i just reviewed one part of code.

Hey i just reviewed one part of code.
Check out what's inside the training dataloader train_features_batch, train_labels_batch = next(iter(train_dataloader)) train_features_batch.shape, train_labels_batch.shape
I cant understand why it gives this when launching
(torch.Size([32, 1, 28, 28]), torch.Size([32]))
Why their sizes and values are not the same? Dont author assigned them together here? How it works?
train_features_batch, train_labels_batch = next(iter(train_dataloader))
Originally posted by @genprokuror in https://github.com/mrdbourke/pytorch-deep-learning/discussions/811

Why is this in issues section ??


Adding create campaign button on the public Campaign page (visible to…

Resolves issue #503
I have added a "Create Campaign" button on the public Campaign page (/Campaign). This button will be displayed if the current user is an org admin or a site admin.

reviewed and so we can :shipit:


GSM charset 7bit

There is implementation with 8bit packing: com.ukarim.smppgui.util.GsmCharset

done in commit ce2e096


ctrl:ruler: Ensure it has store labels

Merging this, as it is simple enough and I want to raise another PR on top.


Fix build breakage on latest nightly

I fixed some build breakages. In general stats uses to many unstable features needlessly. Also, stats uses the antipattern of deny(warnings) which makes it annoying for third-party consumers to build the code.
In the future I might like to reduce criterion's dependency on unstable features or gate them behind flags but for now I just fixed the immediate breakage.

Thank you for your interest, but this issue has been fixed.


How to use third party opensource software

I'm not sure if this is the right place to ask, but information on what to do when you want to include third party opensource software. At least software released under common licenses like MIT, Apache etc. How you should for example include license and copyright notices. Maybe include some good examples.
A quick search gave me these examples:

Facebook
Commvault
Volkswagen
Altova
hangfire.io
Figma
Microsoft Edge
Spotify

Possibly relevant resources:

https://opensource.stackexchange.com/questions/7307/what-is-the-appropriate-way-to-include-third-party-libraries-copyright-notice-an
Easy Attribution Document Generator
https://www.smartcopying.edu.au/open-education/creative-commons/creative-commons-information-pack-for-teachers-and-students/how-to-label-third-party-content-in-creative-commons-licensed-material
https://softwareengineering.stackexchange.com/questions/188152/do-i-have-to-include-the-license-of-a-third-party-library-imported-as-a-dll
https://opensource.stackexchange.com/questions/6081/i-am-using-a-mit-licensed-module-in-a-closed-source-consumer-device-what-are-my

Sorry, this is out of scope for this repository.

Is there a more appropriate place for these kind of suggestions?
Again, it makes no sense there is so little information on this. This site contains info on contributing to, getting paid for, but not how to legally use it...


Add default_auto_field to BlogAppConfig

Description
Add default_auto_field to BlogAppConfig to get rid of Django 3.2 warnings
References
Fixes djangocms-blog related warnings in #737
Checklist

[x] I have read the contribution guide
[x] Code lint checked via inv lint
[x] changes file included (see docs)
[ ] Usage documentation added in case of new features
[ ] Tests added

coverage: 97.094% (+0.1%) from 96.961% when pulling 14b80ba27c8ef7f9ef3e6a93de7fa7013d709fb7 on protoroto:feature/issue-737-add-default-auto-field into bc43947bdaf3fd38d588ba9e9323ff501944d2d0 on nephila:develop.

:+1:


Add ADDITIONAL_SUFFIX environment variable

include in env.sh.example
adjust xgboost training pipeline
adjust Makefile

Description
Adding an additional environment variable RESOURCE_SUFFIX so that GCS asset paths and BQ tables that get overwritten can be suffixed with it, permitting multiple developers on the same project to run pipelines without deleting each others' changes.
I have also tried using pipeline arguments in the compiler for the pipeline. In my opinion this is a worse solution as:

It introduces a lot of additional args to be ran in the Makefile for compile-pipeline, sync-assets and run commands
We already use environment variables for many of the pipeline arguments.

If approach is ok, I will extend to other pipelines (as draft only includes XGBoost training) and update documentation where needed. 05/06/2023: Updated for all pipelines and updated comment in env.sh.example to be comprehensive
How has this been tested?
2 successful pipelines that (with/without ADDITIONAL SUFFIX environment variable set )
Checklist

[x] I have commented my code, particularly in hard-to-understand areas
[x] I have successfully run the E2E tests, and have included the links to the pipeline runs below
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I have updated any relevant documentation to reflect my changes
[ ] I have assigned a reviewer and messaged them

Pipeline run links:

without ADDITIONAL_SUFFIX variable
with ADDITIONAL_SUFFIX variable

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun


.net8 build an image problem

What version of Docker.DotNet?:
3.125.4  3.125.15

Steps to reproduce the issue:

Create an ASP.NET Core WebApi 8.0 project
Add Docker support
Use the current project and Dockerfile to call the BuildImageFromDockerfileAsync method to build the image
Run container using image

Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
USER app
WORKDIR /app
EXPOSE 8080
EXPOSE 8081

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "./WebApplication1/./WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "./WebApplication1.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish
ARG BUILD_CONFIGURATION=Release
RUN dotnet publish "./WebApplication1.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

What actually happened?:
Unhandled exception. System.UnauthorizedAccessException: Access to the path '/app/appsettings.json' is denied.
---> System.IO.IOException: Permission denied
--- End of inner exception stack trace ---
at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirError)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode, Boolean failForSymlink, Boolean& wasSymlink, Func4 createOpenException)    at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Boolean failForSymlink, Boolean& wasSymlink, Func4 createOpenException)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable1 unixCreateMode)    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, Int64 preallocationSize)    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)    at Microsoft.Extensions.Configuration.FileConfigurationProvider.<Load>g__OpenRead|6_0(IFileInfo fileInfo)    at Microsoft.Extensions.Configuration.FileConfigurationProvider.Load(Boolean reload)    at Microsoft.Extensions.Configuration.ConfigurationManager.AddSource(IConfigurationSource source)    at Microsoft.Extensions.Configuration.ConfigurationManager.Microsoft.Extensions.Configuration.IConfigurationBuilder.Add(IConfigurationSource source)    at Microsoft.Extensions.Hosting.HostingHostBuilderExtensions.ApplyDefaultAppConfiguration(HostBuilderContext hostingContext, IConfigurationBuilder appConfigBuilder, String[] args)    at Microsoft.Extensions.Hosting.HostApplicationBuilder..ctor(HostApplicationBuilderSettings settings)    at Microsoft.AspNetCore.Builder.WebApplicationBuilder..ctor(WebApplicationOptions options, Action1 configureDefaults)
at Microsoft.AspNetCore.Builder.WebApplication.CreateBuilder(String[] args)
at Program.$(String[] args) in /src/WebApplication1/Program.cs:line 1
Additional information:
The main reason is because .net8 uses non-root user, but there is no problem when I use docker cli.

I found the problem, I was using the ICSharpCode.SharpZipLib library, and each entry in the tar archive needed to set permissions.
The value of the Mode attribute is an octal number indicating the read, write, and execute permissions for the file. The format of this value is the same as permissions in Linux file systems.
TarEntry.TarHeader.Mode = Convert.ToInt32("0755", 8);

@chrisdaiii could you elaborate a little more on the solution? Looks like you are using testcontainers?
How does the usage of ICSharpCode.SharpZipLib affect the permissions of the appsettings file in the docker container?

NVM. Removing USER $APP_UID worked for me. I guess if this were a prod image it might be worthwhile to update the permissions for the non root user


Add bus factor analyses

@christinaexyou
This is a good first step. Here are some next steps:

[ ] All analysis should be anonymous. Instead of using user last-names, use their unique Augur contributor IDs.
[ ] Bus-factor can be for commits only, but we're also interested in who's directing discourse in issues, working on PRs, reviewing PRs, etc. Let's also investigate those modes of collaboration.
[ ] Squash the commits for this PR into a single commit.
[ ] Provide a thorough description in this PR of what you're trying to analyze.
[ ] Thoroughly document your notebook, mostly as a narrative using markdown, to tell a story with the data.
[ ] Run the notebook on a larger community that would likely have a more distributed workload, so there wouldn't be a single person doing an overwhelming amount of the work.


disable screen power & sleep when in full screen

the screen should not turn off / the pc should not go to sleep on windows if shabad os is in fullscreen, similar to how videos in fullscreen work. not sure of what is the case on mac os.

Duplicate of #357


Youtube frame overlaps the nav bar when scrolling down in the Getting Started Page on IE

Steps

Open up IE
Go to the Getting Started page
Click to play one of the youtube videos
Pause it after a couple of seconds
Scroll down the page

Expected
The page would scroll normally with no overlaps
Actual
The video player frame overlaps the OSF nav bar. This only occurs on IE-10 and only with the videos that are played.

@wisherp can you specify IE version?

@caneruguz This is happening on IE 10

@wisherp I can't replicate this issue can you try again?

@caneruguz I am still seeing this on IE 10 through UVA Hive. It seems to work fine on every other browser so it might be an issue with the Hive rather than the OSF.

Let's go with that for now :smiling_imp:  -- closing. TY!


Remove disabled dependencies

This PR fixes #9052.
What this PR does / why we need it:
In case a chart is referenced multiple times as a dependency with a condition, a false condition is only respected for the dependency that is processed first. The remaining dependencies whose condition is false will get rendered incorrectly.
I found out that the chart dependencyMetadata is initialized once the dependencyChart is loaded (e.g. from the filesystem). This Metadata object is then referenced by all aliased depency Chart.
Once the first dependency is processed, the Metadatas Name is changed to the Alias:
https://github.com/helm/helm/blob/960b3b53c6c30d72c68738fbed3ccf3724b30130/pkg/chartutil/dependencies.go#L143-L145
For the next dependency, the check in Line 132 will fail since req.Name has now changed to the alias:
https://github.com/helm/helm/blob/960b3b53c6c30d72c68738fbed3ccf3724b30130/pkg/chartutil/dependencies.go#L130-L135
The remaining disabled dependencies will therefore not get removed from the list of charts that will be rendered.
I decided to deep-copy theMetadatas dependencies in this PR to prevent metadata corruption.
Special notes for your reviewer:
This PR contains a test case for a chart that renders incorrectly with the current master, but renders correctly with this PR.
The structure of the chart is:
chart-with-dependency-aliased-twice-with-condition:
  childFoo:
    grandchildAlias
  childBar:
    grandchildAlias

If applicable:

[ ] this PR contains documentation
[x] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

The CircleCI build did not run, is it possible to retrigger that?

The CircleCI build did not run, is it possible to retrigger that?

We've seen this occur before when other community members fork Helm and point their fork at another CircleCI account IIRC. I ca't fully recall what's the correct course of action here, but looking at the webhook system from GIthub's end it looks like the webhook payloads are being sent to CircleCI just fine on our end.
Can  you please look into this on your end?

We've seen this occur before when other community members fork Helm and point their fork at another CircleCI account IIRC. I ca't fully recall what's the correct course of action here, but looking at the webhook system from GIthub's end it looks like the webhook payloads are being sent to CircleCI just fine on our end.
Can  you please look into this on your end?

Thanks for the pointer, I have deleted the CircleCI integration on my fork. Can we somehow trigger the build again?

Thanks for the pointer, I have deleted the CircleCI integration on my fork. Can we somehow trigger the build again?

@bacongobbler we also experience this bug, can we get this merged?

I've just stumbled across this bug, and this seems fixed in the latest version if this is the issue you were getting at:
dependencies:
  # Databases
  - name: postgresql
    version: 12.8.0
    repository: oci://registry-1.docker.io/bitnamicharts
    alias: db-a
    condition: db-a.enabled

  - name: postgresql
    version: 12.8.0
    repository: oci://registry-1.docker.io/bitnamicharts
    alias: db-b
    condition: db-b.enabled

This works.

Tested your repro with helm 3.12.2. Still a problem.

Please can we have this merged ? This is a real issue for us
we have a helm chart A with a conditional dependency on redis:
`dependencies:

name: redis
version: 17.3.8
condition: redis.enabled
`

in the application we reference multiple time the chart A as dependency:
`dependencies:

name: A
alias: application1
name: A
alias: application2
`

with following values.yaml:
`application1:
redis:
enabled: false
application2:
redis:
enabled: true`
Impossible to get a stable rendering of the final chart, sometimes the redis is rendered, sometimes not, I have the impression it depends on the name of application1 and 2 (so of the ordering of the processing by helm)
That matches the content of this MR, thanks @oliviermichaelis for the fix
Why isn't merged yet?

The code does work, but not sure that TestChartWithDependencyAliasedTwiceWithCondition() is testing this fully. Here's what a manual test gives:

first, we need to update the test chart included in this PR to:
$ git diff pkg/chartutil/testdata/chart-with-dependency-aliased-twice-with-condition/charts/child/charts/grandchild/templates/service.yaml
...
@@ -1,7 +1,7 @@
 apiVersion: v1
 kind: Service
 metadata:
-  name: {{ include "grandchild.fullname" . }}
+  name: {{ include "grandchild.fullname" . | lower }}
   labels:
     {{- include "grandchild.labels" . | nindent 4 }}
 spec:

otherwise it will fail with:
$ helm install test pkg/chartutil/testdata/chart-with-dependency-aliased-twice-with-condition \
  --set childFoo.grandchildAlias.enabled=true
Error: INSTALLATION FAILED: 1 error occurred:
    * Service "test-grandchildAlias" is invalid: metadata.name: Invalid value: "test-grandchildAlias": a DNS-1035 label must consist of lower case alphanumeric characters or '-', start with an alphabetic character, and end with an alphanumeric character (e.g. 'my-name',  or 'abc-123', regex used for validation is '[a-z]([-a-z0-9]*[a-z0-9])?')

because while Helm has ValidateReleaseName() in pkg/chartutil/validate_name.go, the dependency alias when passed to .Chart.Name` doesn't validate on install/upgrade, so (for now) we can only test by converting to lower in the template before attempting to create a service with an uppercase character ("grandchildAlias").

now we can reproduce the error:
$ helm install test pkg/chartutil/testdata/chart-with-dependency-aliased-twice-with-condition \
  --set childFoo.grandchildAlias.enabled=true
  NAME: test
  STATUS: deployed
  ...

$ k get all
NAME                            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/test-grandchild        ClusterIP   <IP_ADDRESS>      <none>        80/TCP    12s
service/test-grandchildalias   ClusterIP   <IP_ADDRESS>   <none>        80/TCP    12s

I see the error is there is one dependency chart's template installed—using the alias. And another installed using the dependency name—not the alias. Only the first one should have been created.
If you change the order, and only enable the 2nd dependency in the list --set childBar.grandchildAlias.enabled=true instead, you get only the dependency chart's template installed using the dependency name—not the alias:
$ helm uninstall test
$ helm install test pkg/chartutil/testdata/chart-with-dependency-aliased-twice-with-condition \
  --set childBar.grandchildAlias.enabled=true
NAME                      TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/test-grandchild   ClusterIP   <IP_ADDRESS>   <none>        80/TCP    3s

Test this PR. Seems to fix it:
$ helm uninstall test
$ gh pr checkout 9184
$ make build
# test first case above
$ ./bin/helm install test pkg/chartutil/testdata/chart-with-dependency-aliased-twice-with-condition \
  --set childFoo.grandchildAlias.enabled=true
  ...

$ k get all
NAME                           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/test-grandchildalias   ClusterIP   <IP_ADDRESS>   <none>        80/TCP    2s

# test second case above
$ ./bin/helm install test pkg/chartutil/testdata/chart-with-dependency-aliased-twice-with-condition \
  --set childBar.grandchildAlias.enabled=true
$ k get all
NAME                           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
service/test-grandchildalias   ClusterIP   <IP_ADDRESS>   <none>        80/TCP    3s

Fun note, if you want to test enabling both dependencies, you'll need to do a name override on one of the grandchildren charts, otherwise the service will fail creation because the same name will be used and service/test-grandchildalias already exists. Like this:
$ helm install pkg/chartutil/testdata/chart-with-dependency-aliased-twice-with-condition \
  --set childFoo.grandchildAlias.enabled=true \
  --set childBar.grandchildAlias.enabled=true \
  --set childBar.grandchildAlias.nameOverride=bar-grandchild
$ k get all
              TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
service/test-bar-grandchild    ClusterIP   <IP_ADDRESS>   <none>        80/TCP    2s
service/test-grandchildalias   ClusterIP   <IP_ADDRESS>   <none>        80/TCP    2s

So good work on the code change. Correct me if I'm wrong about the automated test—not sure it covers this fully.

Thanks for your effort @scottrigby, much appreciated! I incorporated your feedback about the invalid resource name in a1b5d6f0222247589dfdfa6c31257a9ab9b856e2.

Correct me if I'm wrong about the automated test—not sure it covers this fully.

Can you be more specific about this statement, please? What exactly is missing? This is the first time I'm looking at my code from a couple of years ago and I'm certainly missing something. Thanks!

Thanks for your effort @scottrigby, much appreciated! I incorporated your feedback about the invalid resource name in ffd5d61.

Correct me if I'm wrong about the automated test—not sure it covers this fully.

Can you be more specific about this statement, please? What exactly is missing? This is the first time I'm looking at my code from a couple of years ago and I'm certainly missing something. Thanks!

What I meant was that if the unit test didn't catch the template bug I found, then why are we adding templating in the test chart.
You're right that for this single use case/bugfix, the test covers it ok. We are processing only the dependencies.
Given that, can you please simplify the testdata chart to have only the bare minimum needed for the test itself? It doesn't need boilerplate comments, values, or even templating. That will make it more clear what the test chart is for when paired with the unit test. And then I think this will be good to go.


add tests for geodesic Sinkhorn

In #633 , we currently only have tests for the TemporalProblem. As the pipeline for a graph-based cost is quite different from the remaining costs, we need tests for all problems. Moreover, we should test for different configurations of costs, e.g. linear term geodesic, quadratic terms Euclidean.
Finally, we need examples on how to use the geodesic cost. Here, I would suggest one example notebook for multiple time points with the TemporalProblem, and one FGW problem (e.g. TranslationProblem) with the linear term being geodesic, and the quadratic e.g. cosine cost.

solved with https://github.com/theislab/moscot/pull/677


HCK-7747: "Collation" is not cleared in DB2 on model level

HCK-7747  "Collation" is not cleared in DB2 on model level

UTF-8 requires fixes in studio. rasing another bug


include: posix: unistd: Fix prototypes and dependency

For read/write/lseek, use size_t and off_t types, as mandated by
POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html
Also, prototypes of unistd.h functions should not depend on
CONFIG_POSIX_FS, as (many) of them deal with generic I/O, not with
files in filesystem per se.
Signed-off-by: Paul Sokolovsky<EMAIL_ADDRESS>

Codecov Report

Merging #10438 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #10438   +/-   ##
=======================================
  Coverage   53.14%   53.14%
=======================================
  Files         210      210
  Lines       25745    25745
  Branches     5673     5673
=======================================
  Hits        13681    13681
  Misses       9754     9754
  Partials     2310     2310

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24bfa40...2bd5db9. Read the comment docs.

@pfalcon thank you for taking care of this.

@nashif

@pfalcon thank you for taking care of this.

So, hoping for a prompt review ;-).

@nniranjhana :

Also, you might wanna change the test_file_write.c

Thanks, added commit for that.


Fix bug for https://github.com/apache/camel/pull/10400

For detail see https://github.com/apache/camel/pull/10400, this PR fixed a bug.

@EvanMi can you check camel-undertow, it has failure with RestUndertowHttpGetCorsTest

@davsclaus I found the problem out, the reason is that /users/{a}/b?restrickedMethod=GET&OPTIONS /users/{a}/b?restrickedMethod=POST&OPTIONS , these two routes a all match when options request coming in.Should i treat OPTIONS as special? Or an good advice?

@davsclaus I found the problem out, the reason is that /users/{a}/b?restrickedMethod=GET&OPTIONS /users/{a}/b?restrickedMethod=POST&OPTIONS , these two routes a all match when options request coming in.Should i treat OPTIONS as special? Or an good advice?

@davsclaus with this condition add, test passed

Yeah options is special


feat(templates): add ability to call templates within a template

Closes https://github.com/go-vela/community/issues/256
Using a configurable max depth, this change would allow Vela users to call templates within templates.
Note: since compileInline doesn't call ExpandSteps and my first few passes on getting it to work similarly failed, I left support for render_inline as TO-DO.

We may want to consider adding some caching for the getTemplate function to avoid fetching the same templates multiple times.

We may want to consider adding some caching for the getTemplate function to avoid fetching the same templates multiple times.
EDIT: the extra compile duration caused by these changes could be concerning without caching since GitHub expects a response to webhooks within 10 seconds for github.com or 30 seconds for GHES.

I really like the idea of caching templates. I know we have at least a few templates that have widespread usage and definitely would take up permanent residence in that cache.
As for the extra compile duration, that is definitely something to consider. In my testing the responses were rather quick, but since template depth is renewed for each individual step, it could definitely get messy with dozens of steps each calling a chain of templates. It would be worth investigating some of those recommendations in the links related to queuing up work and giving the SCM a quick response...

Putting in draft for now. Let's reopen this discussion after v0.19 is released?

Bringing this out of draft

putting this back in draft, as I decided to tackle render_inline instead of leaving it as a to-do 👍


Apply for render algorithm code

Hi Tsattler,
It is an impressive works. I see the render code in meshloc is not available anymore(https://arxiv.org/pdf/1601.06950.pdf), but its very important for my reaserch. I would very appriciate, if you could provide me the MeshLoc's render algorithm.  Or, there is another render engine/algorithms is avaliable (as you know).
Thank you so much! Looking forward to your reply.

Hi @Choyaa,
we had issues with rendering very large models in Open3D, which seem to be still present (see this Open3D issue), however it works for the models presented in our paper.
Note that I had to use Open3D 0.15, as I get a Segmentation fault in 0.16 (probably connected to this issue).


[FormRecognizer] Tests: implemented model caching

API change check
API changes are not detected in this pull request.

/azp run net - formrecognizer - tests

/azp run net - formrecognizer - tests


Add WATCH_NAMESPACE env var to operator deployment

Overview
It is recommended to add the WATCH_NAMESPACE environment variable to an operators deployment[1], which will allow the generate csv command to modify the value of this to "metadata.annotations['olm.targetNamespaces']". Currently, the enmasse operator deployment has an env var called NAMESPACE[2].
I am not sure if the NAMESPACE env var is used internally in the enmasse operator or if there is a limitation stopping the addition of WATCH_NAMESPACE or replacing the NAMESPACE env var.
[1] https://github.com/operator-framework/operator-sdk/blob/8a8e2b160afff3741c676e79862d0134b14a6e59/internal/generate/olm-catalog/csv_updaters.go#L36
[2] https://github.com/EnMasseProject/enmasse/blob/master/templates/enmasse-operator/050-Deployment-enmasse-operator.yaml#L40

We don't generate the CSV using operator-sdk at present, but it something we aim to do for 1.0. Likewise, we want to be able to watch only a single namespace in 1.0 as well, so adding the 1.0 milestone to this task.

Thank you for the response @lulf . That makes sense


Cannot access pretrained model and custom bible dataset (Dropbox 404)

Pretrained files:
https://u42868014.dl.dropboxusercontent.com/u/42868014/tacotron/logdir_s.zip
Audio data (custom split by sentence):
https://dl.dropboxusercontent.com/u/42868014/WEB.zip
Text matching audio:
https://dl.dropboxusercontent.com/u/42868014/text.csv
Is there any secondary link where we can get the training dataset and models from?

The same problem! Maybe someone already has it and can share?

the same

the same

the same 👍

I apologise for this, guys. I don't know why the dropbox links stopped working. But, anyway I've created new links. Check them out.

Can you load the text.csv first? Thank you

Is there any chance for a torrent-like link? My internet decided to cut out at 7/8.4 GB and I had to download it all over again, probably others would benefit from this (as would I if I need to download it again someday).


Enable docker image cross build on Fedora

Currently check_buildx in builds/networking/scripts/ipdk-lib.sh only
checks update-binfmt which is Ubuntu binfmt_misc facilities. Fedora uses
service systemd-binfmt. So add checking of this if distribution is Fedora.
Signed-off-by: Jason Zeng<EMAIL_ADDRESS>

close #130

@mestery or other maintainer: can you please kick off the lingering GH Actions workflow for this PR? Thanks!

If the CI is positive then its a LGTM from me...


[bug] Accordion doesn't open when arrow icon is tapped

Describe the bug
Tapping (not sure about clicking) the arrow icon in the accordion header doesn't expand the accordion panel.
Which Component?
rh-accordion
Steps to reproduce

Go to https://ux.redhat.com/elements/accordion/#sample-element
Click directly on the arrow
Notice that the panel doesn't expand
I'm on a mobile device. Not sure if that matters.

Expected behaviour
The accordion should expand
Screenshots
No response
Element HTML
No response
Operating System (OS)
Linux
Browser
Chrome
More browser information

Chrome on Android

Additional Info
No response

Can probably fix with pointer events: none on the icon

It looks like there isn't an issue with the component itself. When I visit https://ux.redhat.com/elements/accordion/demo/ on my mobile device, the accordion works properly. I wonder if there's something wrong with https://ux.redhat.com/elements/accordion/

i tried this on ff 118, chromium 118 and GNOME web 45, and in all three, clicking the chevron icon toggled the accordion panel


fast appointment end time, suggest the appointment duration time.

When a new appointment is being made and the start time is made, we can choose scheduling for 15, 30 or 60 minutes, otherwise just set manually the end time of the meeting.

I've already discussed this with the design team, they're gonna give us a proposal :)


Session info missing when url includes a '.' e.g: '/images/:userID/:file' with '/images/14/avater.png'

Sails version: v1.0.0-40
Node version: v8.1.2
NPM version: 5.4.2
DB adapter name: sails-mysql
DB adapter version: N/A
Operating system: Ubuntu 16.04

Hey guys,
If I include a period in a url, req.isAuthenticated() returns false.
I am using passport for managing authentication and redis for my session management.
Here is my policy (I have check it is called):
module.exports = function(req, res, next) {
  if (req.isAuthenticated()) {
    return next();
  } else {
    return res.redirect('/login');
  }
};

Here is my route:
'GET r|/dashboard/datasets/view/(\\d+)/assets/(.*)$|datasetId,wantedFile': {
    controller: 'DashboardController',
    action: 'viewDatasetAssets',
    skipAssets: false
  },

Here is my policies.js:
module.exports.policies = {
  '*': true,

  'DashboardController': {
    '*': 'isAuthenticated'
  },

};

Here is a working url: (req.isAuthenticated() == true)
http://host:port/dashboard/datasets/view/14/assets/my/files/hello
Here is a failing url: (req.isAuthenticated() == false)
http://host:port/dashboard/datasets/view/14/assets/my/files/hello.txt
Let me know if you need any more information!
Thanks

ok, fixed!

@mrminecart, starting with Sails 1.0, session support is disabled by default in asset routes.  Besides generally being more efficient, this avoids hard-to-debug issues where, for example, a loading spinner on a "log in" button causes a race condition with two cookies being set for the same domain.
To customize which routes get session support, use the sails.config.session.isSessionDisabled config function.
From the docs:

A function to be run for every request which, if it returns a “truthy” value, will cause session support to be disabled for the request (i.e. req.session will not exist). By default, this function will check the request path against the sails.LOOKS_LIKE_ASSET_RX regular expression, effectively disabling session support when requesting assets.

You can ensure session support for every route by setting this to function() { return false; }.  Or, write some logic that will turn on session support just for routes that match certain patterns.


Add support for Caddyfile Loader and Event Hook plugins

I've tried this and just ended up with an error.
docker build --build-arg \
    plugins=filemanager,git,docker \
    github.com/abiosoft/caddy-docker.git

plugin not found
plugin not found
Cloning into '/go/src/github.com/caddyserver/builds'...
caddymain/run.go:34:2:
../caddyhttp/docker.go:2:10: invalid import path: ""
2018/05/02 05:12:23 exit status 1
exit status 1
The command '/bin/sh -c VERSION=${version} PLUGINS=${plugins} /bin/sh /usr/bin/builder.sh' returned a non-zero code: 1

Fixed :)
Kindly confirm if it works for you now.

Works perfectly. Thank you.