Hi,
I admire Andrew's enthousiasm and would happily let him tackle the next bug
reported in this area ;-)
I could reproduce the deadlock with the same stack trace and have pushed a fix
per https://trac.osgeo.org/gdal/ticket/6661. This was actually not a typical
deadlock situation, but a undef
Sure Andrew,
Here it is the call stack from Visual Studio for both threads (I just copied
the top calls where GDAL is involved, just for easy reading. If you need the
whole stack just let me know):
THREAD 1:
ntdll.dll!_NtWaitForSingleObject@12‑() Unknown
ntdll.dl
Deadlocks are usually easy to debug if you can get a traceback when
deadlocked. If you can attach with gdb (or run in the debugger) and
reproduce and post the stack at the time ('where' from gdb), it should be
no problem to fix. Trying to reproduce on different hardware can be
difficult.
On Mon,
Hi guys,
I am experiencing a deadlock with just 2 threads in a single reader & multiple
writer scenario. This is, threads read from the same input file (using
different handlers) and then write different output files. Deadlock comes when
the block cache gets filled. The situation is the followi
To confirm, gdalinfo --formats shows:
HDF5 (ros): Hierarchical Data Format Release 5
HDF5Image (ro): HDF5 Dataset
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Le lundi 26 septembre 2016 04:10:06, JIA Pei a écrit :
> Hi, all:
>
> I actually would like to enable as many packages as possible for gdal, but
> it seems even if I strictly following "*./configure --hel*p", some packages
> are still NOT able to be configured correctly.
> For instance, *HDF5* (in
