osm2navit segfaults on specific (big) osm

[http://pavelmachek.livejournal.com/]

gdb says:

PROGRESS: sorting 373 tiles done
PROGRESS: merged 0 tiles
PROGRESS3: Processed 124551 nodes (0 out) 1324824 ways 0 relations 11586 tiles
PROGRESS: Phase 5: assembling map 
Maximum slice size 1073741824
Slice 0 is of size 156333892
PROGRESS4: Processed 0 nodes (0 out) 0 ways 0 relations 0 tiles
PROGRESS4: Processed 124551 nodes (0 out) 1324824 ways 0 relations 0 tiles
[New Thread 0xb7c738c0 (LWP 26994)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7c738c0 (LWP 26994)]
write_zipmember (zip_info=0xbfb35334, name=0x815a678 "adbdadcbd", filelen=14, 
    data=0xb2c6f5dc "\021", data_size=10792692) at osm2navit.c:2739
2739		crc=crc32(0, NULL, 0);
(gdb) 
(gdb) bt
#0  write_zipmember (zip_info=0xbfb35334, name=0x815a678 "adbdadcbd", filelen=14, 
    data=0xb2c6f5dc "\021", data_size=10792692) at osm2navit.c:2739
#1  0x0805285e in main (argc=Cannot access memory at address 0xe
) at osm2navit.c:2815

[http://pavelmachek.livejournal.com/]

I believe I see the problem:

uLongf destlen=data_size+data_size/500+12; char compbuffer[destlen];

... that breaks the stack. if destlen is too big (10MB in my case), system will not recognize pagefault as belonging to the stack, and just die die die...

[http://pavelmachek.livejournal.com/]

this confirms problem is indeed with too big stack allocation; with this patch it works for me

[Tinloaf]

Applied in revision 2210.

[http://pavelmachek.livejournal.com/]

Well, if only it was that easy. Yes, the patch I posted fixes it (and proves stack space really is a problem); but by mallocing() and never freeing it introduces memory leak; that is at least unnice. I'll look if I can provide better fix.

[Tinloaf]

I did not just apply your patch - did you have a look at the patch I applied in revision 2210? It frees the compbuffer - or did I miss something introducing a memory leak there?

[http://pavelmachek.livejournal.com/]

Aha, I assumed you applied it without changes based on the comment above. I checked the code now, and it seems to be okay. Sorry about the noise.