crash on GDALOpen of GeoTIFF in WinCE build

I see that TIFFFindField() can easily call bsearch() with num=0, but it isn't clear to me why this should cause a problem. Perhaps the wceex_bsearch() implementation needs handling for this case?

I can fix libtiff if it can be demonstrated that it is inappropriate to call bsearch() this way.

Can you confirm you are using the same wceex_bsearch() implementation found at:

http://wcelibcex.svn.sourceforge.net/viewvc/wcelibcex/trunk/src/wce_bsearch.c?view=markup

This seems to have an assert on line 58, and I don't see how anything could go wrong with the parameters in your traceback. In particular if num=0, then left=0, right=-1, and the loop should be skipped resulting in the function safely returning NULL.

Perhaps you have an old (buggy) version of wcelibcex?

Mloskot notes in IRC:

<mloskot> FrankW:  if num is 0, then right = -1
<mloskot> and NULL is returned
<mloskot> because while condition is false on start
<mloskot> while (0 <= -1)
<mloskot> and no searching is issues
<mloskot> issued
<mloskot> that's my diagnosis but I've no idea why num is 0 - the most important part ;-)
<mloskot> FrankW:  AFAIK, my bsearch function works as POSIX defines it
<mloskot> http://www.opengroup.org/onlinepubs/000095399/functions/bsearch.html
<mloskot> "If the nel argument has the value zero, the comparison function pointed to by compar shall not be called and no match shall be found."
<mloskot> where "nel" is my num
<mloskot> and null pointer is returned if no match found

This matches my understanding. So I'm left not knowing why things are crashing as you see.

At least you should try to establish if it is an assert() triggering the crash or something else.

I've not tested GTiff driver under Windows CE since 1.4.2. I'm back home in Sunday and then I will be able to test it.

fbausch,

It would be helpful and faster for me if I could use the same file as you do. Could you send me one?

fbauche writes:

i am using the wcelibcex 1.0, and it appears that right is unsigned - and instead of holding the value -1, is instead holding a vary large positive value.

i do not think it is an assert failing, rather an infinite loop. the thread dies without allowing any access through the debugger - and the call stack provided is not the stack after the crash, but the stack before it enters into the loop in which the crash happens.

thanks for your attention - i'm happy to continue working to isolate this problem.

f.

---

Your analysis is correct. wce_bsearch needs to check for the case of num==0 since size_t is (at least on some systems) unsigned. I hadn't considered this. Turning over to Mateusz to correct.

further work on this points to several issues -
1) in wcelibcex, wce_bsearch needs to check for the case of num==0 since size_t is (at least on some systems) unsigned.
2) in GDAL, frmts/gtiff/libtiff/tif_config.h.wince, #define TIFF_UINT16_T short causes problems, and needs to be <unsigned short>
3)in GDAL, frmts/gtiff/libtiff/tif_dirinfo.c - in the tagCompare routine: when tagCompare is called in this chain: TIFFFindField - bsearch - tagCompare the second return statement appears to be slightly wrong: a wildcard field_type (TIFF_ANY) can be set for the b parameter(the tb tag), which would then allow a field_tag match to return success.
Other call sequences that lead to tagCompare may be different, but in the sequence through TIFFFindField, it is the b parameter which can hold the wildcard type specification, and not the a parameter.
the change below fixes the wildcarding operation
static int tagCompare(const void* a, const void* b) {

const TIFFField* ta = *(const TIFFField**) a; const TIFFField* tb = *(const TIFFField**) b; /* NB: be careful of return values for 16-bit platforms */ if (ta->field_tag != tb->field_tag)

return (int)ta->field_tag - (int)tb->field_tag;

else

// return (ta->field_type == TIFF_ANY) ?
// 0 : ((int)tb->field_type - (int)ta->field_type);

return (tb->field_type == TIFF_ANY) ? // changed return

0 : ((int)tb->field_type - (int)ta->field_type);

}
with these changes, it appears that my problems reading GeoTIFF files are resolved.

As already mentioned in #2151 part 2 of the above fix together with the fix in #2151 solved also my gtiff problems on wince.