Opened 9 years ago

Closed 9 years ago

#3026 closed defect (fixed)

[Atlas] crash when zooming out on a map

Reported by: serveurix Owned by: philip
Priority: Must Have Milestone: Alpha 18
Component: Atlas editor Keywords: crash, atlas, vbo
Cc: Patch:

Description (last modified by serveurix)

I'm editing some maps with the last svn, and when I zoom out, Atlas segfaults at a certain level of zoom, with the following message:

ERROR: Failed to create VBOs (64*32827) ERROR: Failed to allocate VBO for vertex array Erreur de segmentation

Could this be related to: r16241 ?

Debian Jessie with Radeon R9 280X, Catalyst driver. Edit: happens with radeon too.

Update: When I'm moving the camera angle sometimes I get the error messages printed on screen, but no crash. I also have a shadow appearing all over the map under certain camera angles.

Update: The map on which I have the problem. Note that this map was created *before* the last VBO commit.

Attachments (3)

ziggurat4.xml (71.7 KB ) - added by serveurix 9 years ago.
ziggurat4.pmp (641.3 KB ) - added by serveurix 9 years ago.
logs.tar.gz (7.2 KB ) - added by serveurix 9 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 by serveurix, 9 years ago

Description: modified (diff)

comment:2 by Stan, 9 years ago

Could you provide a crashdump and system info ? :)

comment:3 by Simon Georges, 9 years ago

Component: Core engineAtlas editor

comment:4 by Niek, 9 years ago

Description: modified (diff)
Milestone: BacklogAlpha 18
Priority: Should HaveMust Have
Summary: Atlas : crash when zooming out on a map[Atlas] crash when zooming out on a map

comment:5 by Philip Taylor, 9 years ago

I thought I could get away with making the VBOs a bit smaller (2MB instead of 4MB) to reduce the wasted memory, but evidently I can't :-(

comment:6 by Philip Taylor, 9 years ago

Hmm, actually I'm not sure that's really the problem... Even on a huge map like "Eire and Albion", I don't see any allocations larger than 64*10327, which easily fits within the 2MB limit, so I'm not sure what's causing such a huge allocation in this case.

It would probably be helpful to get a stack trace by running it in gdb - that should indicate where the allocation is happening. If it happens repeatedly on a particular map, it would be helpful to know which map (or get a copy if it's a custom map).

comment:7 by Stan, 9 years ago

Maybe try on the unit display map.

by serveurix, 9 years ago

Attachment: ziggurat4.xml added

by serveurix, 9 years ago

Attachment: ziggurat4.pmp added

comment:8 by serveurix, 9 years ago

Description: modified (diff)

by serveurix, 9 years ago

Attachment: logs.tar.gz added

comment:9 by historic_bruno, 9 years ago

Here's some instructions on how to get a 0 A.D. crash backtrace on Linux: Debugging

comment:10 by serveurix, 9 years ago

Description: modified (diff)

in reply to:  10 comment:11 by Niek, 9 years ago

Replying to serveurix: with what radeon does it happen too?

comment:12 by Philip Taylor, 9 years ago

Looks like art/meshes/structural/pers_gardens_struct.dae has a crazy number of vertexes - normally 32410, and if you turn on preferglsl+gentangents it goes up to 32827. Each vertex takes 64 bytes in the VBO, so 32827 exceeds 2MB and it fails. I can increase the limit back up to 4MB. (Seems an excessively large mesh, though...)

comment:13 by Stan, 9 years ago

It's because of all the plants on it, Enrique did a really good detail job on it.

comment:14 by philip, 9 years ago

Owner: set to philip
Resolution: fixed
Status: newclosed

In 16309:

Increase max VBO size back to 4MB.

Some meshes (e.g. pers_gardens_struct with gentangents enabled) have >32K vertexes, and won't fit in a 2MB VBO. r16241 had reduced them from 4MB to 2MB. So just make the VBOs bigger again, and try not to worry about the waste of memory.

Fixes #3026, #3042.

Note: See TracTickets for help on using tickets.