Well, I've also found that issue: strdup (s=0x0) Found and corrected. It's was also a big issue :$
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74 #1 0x00007ffff4fa8583 in __GI___strdup (s=0x0) at ./string/strdup.c:41 #2 0x00007ffff6f4c075 in MMInitLayerToRead (hMiraMonLayer=0x5555560b57e0, m_fp=0x555555d5e590, pszFilename=0x555555d4f970 "/vsimem/test1067.pol") at /gdal/ogr/ogrsf_frmts/miramon/mm_rdlayr.c:146 #3 0x00007ffff6f2e03a in OGRMiraMonLayer::OGRMiraMonLayer (this=0x555556087b10, pszFilename=0x555555d4f970 "/vsimem/test1067.pol", fp=0x0, poSRS=0x0, bUpdateIn=0, papszOpenOptions=0x0, MMMap=0x55555607b5c0) at /gdal/ogr/ogrsf_frmts/miramon/ogrmiramonlayer.cpp:219 #4 0x00007ffff6f2c8b5 in OGRMiraMonDataSource::Open (this=0x55555607b460, pszFilename=0x555555d4f970 "/vsimem/test1067.pol", fp=0x0, poSRS=0x0, bUpdateIn=0, papszOpenOptionsUsr=0x0) at /gdal/ogr/ogrsf_frmts/miramon/ogrmiramondatasource.cpp:71 #5 0x00007ffff6f2d268 in OGRMiraMonDriverOpen (poOpenInfo=0x7fffffffdd00) at /gdal/ogr/ogrsf_frmts/miramon/ogrmiramondriver.cpp:87 #6 0x00007ffff73d0819 in GDALDriver::Open (this=0x555555640cb0, poOpenInfo=0x7fffffffdd00, bSetOpenOptions=false) at /gdal/gcore/gdaldriver.cpp:116 #7 0x00007ffff73e9980 in GDALOpenEx (pszFilename=0x555555d53d50 "/vsimem/test1067.pol", nOpenFlags=14, papszAllowedDrivers=0x0, papszOpenOptions=0x0, papszSiblingFiles=0x0) at /gdal/gcore/gdaldataset.cpp:3745 #8 0x00007ffff73d4be7 in GDALDriver::Delete (this=0x555555640cb0, pszFilename=0x555555d53d50 "/vsimem/test1067.pol") at /gdal/gcore/gdaldriver.cpp:1645 #9 0x000055555555e6f0 in TestCreateLayer (poDriver=0x555555640cb0, eGeomType=wkbLineString) at /gdal/apps/test_ogrsf.cpp:1017 #10 0x000055555555ef8f in TestCreate (poDriver=0x555555640cb0, bFromAllDrivers=1) at /gdal/apps/test_ogrsf.cpp:1107 #11 0x000055555555bdb2 in ThreadFunctionInternal (psContext=0x7fffffffe400) at /gdal/apps/test_ogrsf.cpp:325 #12 0x000055555555bc71 in ThreadFunction (user_data=0x7fffffffe400) at /gdal/apps/test_ogrsf.cpp:283 #13 0x000055555555bac1 in main (nArgc=2, papszArgv=0x555555645050) at /gdal/apps/test_ogrsf.cpp:233 -----Mensaje original----- De: gdal-dev <gdal-dev-boun...@lists.osgeo.org> En nombre de Abel Pau via gdal-dev Enviado el: dilluns, 4 de març de 2024 10:42 Para: Even Rouault <even.roua...@spatialys.com>; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions After some investigations, I've concluded that I was doing two things that I've improved lately: 1) Addressing a memory leak (in a non-typical case in my previous tests). CORRECTED 2) I was requesting an amount of memory suitable for ogr2ogr of large layers but not for numerous translations on a machine with limited memory. I've reduced the amount of memory required by /10. And now Alpine 32 bits is in green colour! There are still some tests to review, but I'm optimistic about submitting a pull request soon! -----Mensaje original----- De: gdal-dev <gdal-dev-boun...@lists.osgeo.org> En nombre de Abel Pau via gdal-dev Enviado el: divendres, 1 de març de 2024 16:18 Para: Even Rouault <even.roua...@spatialys.com>; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions Yes, I hope it's only ONE single mistake because I have my code very protected against that kind of things... Before you said that I am using LOG_STR(); from the test and I've filled it in all possible place it could be something. Remember I have windows and in Visual Studio it works fine... I don't know how to debug in my Docker linux (only command line) with Cmake compiler... I think I'll catch the problem. Sooner or later! I've been there before (years ago with a big problem (not my fault)). Finally I win -----Mensaje original----- De: Even Rouault <even.roua...@spatialys.com> Enviado el: divendres, 1 de març de 2024 16:12 Para: Abel Pau <a....@creaf.uab.cat>; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions Your code must be something terrible so that even gdb doesn't catch it :-) (SIGKILL cannot be caught...) From the error messages, things might go wrong starting with https://github.com/OSGeo/gdal/blob/master/apps/test_ogrsf.cpp#L782 So maybe set a breakpoint at that line b test_ogrsf.cpp:782 and then use "step", and "next" to single step and locate where this crashes. This is going to be a bit tedious... (you might also want to modify slightly test_ogrsf so that this TestCreateLayer() method exists early when !EQUAL(poDriver->GetDescription(), "miramon") to avoid debugging other drivers) You might install "ddd", as a GUI front-end for gdb, so that this is slightly more user friendly. -- http://www.spatialys.com My software is free, but my time generally not. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev