Frama-C runs out of memory on small C program (combinatorial explosion in analysis of "main"?)
ID0002189: **This issue was created automatically from Mantis Issue 2189. Further discussion may take place here.** --- | **Id** | **Project** | **Category** | **View** | **Due Date** | **Updated** | | --- | --- | --- | --- | --- | --- | | ID0002189 | Frama-C | Plug-in > wp | public | 2015-12-03 | 2015-12-03 | | | | | | | | | --- | --- | --- | --- | --- | --- | | **Reporter** | Jochen | **Assigned To** | correnson | **Resolution** | open | | **Priority** | normal | **Severity** | tweak | **Reproducibility** | always | | **Platform** | Sodium-20150201 | **OS** | - | **OS Version** | xubuntu14.04 | | **Product Version** | Frama-C Sodium | **Target Version** | - | **Fixed in Version** | - | ### Description : Running "frama-c -wp -wp-rte -wp-prover none 10g.c" on the attached program causes Frama-C to run out of memory after allocation of 3 GBytes memory (deliberately restricted by "ulimit -v 3000000" to avoid swapping/paging). This phenomenon disappears e.g. if * "main" is renamed to "foo" in line 28, * both "p1" and "p2" are made "static" in line 23,24, or * field "e0" or "e1" is removed from the "struct S" definition in line 9,14, and its use in line 33/34 is also removed. Probably, there is some combinatorial explosion effect in the analysis. While this isn't a real bug, it may be worthwile to look after it, since the circumstances under which it can be observed are quite strange. ## Attachments - [10g.c](/uploads/bd7968263c9a1d7ed8fbd893f14eef3f/10g.c)
issue