Opened 14 years ago
Closed 14 years ago
#344 closed defect/bug (fixed)
osm2navit segfaults on specific (big) osm
Reported by: | pavelmachek.livejournal.com | Owned by: | cp15 |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | mapdrivers/OSM | Version: | git master |
Severity: | Keywords: | ||
Cc: |
Description
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
Attachments (1)
Change History (6)
comment:1 Changed 14 years ago by pavelmachek.livejournal.com
Changed 14 years ago by pavelmachek.livejournal.com
this confirms problem is indeed with too big stack allocation; with this patch it works for me
comment:2 Changed 14 years ago by Tinloaf
- Resolution set to fixed
- Status changed from new to closed
Applied in revision 2210.
comment:3 Changed 14 years ago by pavelmachek.livejournal.com
- Resolution fixed deleted
- Status changed from closed to reopened
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.
comment:4 Changed 14 years ago by 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?
comment:5 Changed 14 years ago by pavelmachek.livejournal.com
- Resolution set to fixed
- Status changed from reopened to closed
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.
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...