Opened 12 years ago

Closed 11 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)

delme (449 bytes) - added by pavelmachek.livejournal.com 12 years ago.
this confirms problem is indeed with too big stack allocation; with this patch it works for me

Download all attachments as: .zip

Change History (6)

comment:1 Changed 12 years ago by 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...

Changed 12 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 12 years ago by Tinloaf

  • Resolution set to fixed
  • Status changed from new to closed

Applied in revision 2210.

comment:3 Changed 11 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 11 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 11 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.

Note: See TracTickets for help on using tickets.