#2062 std::bad_alloc

open
nobody
None
5
2012-07-15
2012-07-15
Arnost Vecerka
No

I have installed new version of SDCC compiler (file sdcc-3.2.0a-setup.exe) and tried to compile program which has two source files. Compilation of the first file terminated with message:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Caught signal 22: SIGABRT
sdcpp.exe: fatal error: when writing output to : No error

Compilation of the second file terminated with similar message:

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Caught signal 22: SIGABRT

Parameters of compilation: -c --std-sdcc99 --opt-code-speed --disable-warning 154

SDCC version 3.0 compiles both source files without problems.

Arnost Vecerka

Discussion

  • Borut Ražem
    Borut Ražem
    2012-07-15

    Arnost, please provide some more info:
    - whch Windows version are you using
    - run sdcc with -V option to see which executable is failing and it's arguments and report the result
    - a short c source file and the sdcc command line which reproduces the defect

    Can you please try to compile the same programs with sdcc-3.2.0-setup.exe (not 3.2.0a)?

    Borut

     
  • Arnost Vecerka
    Arnost Vecerka
    2012-07-16

    Operating system: Windows XP Professional SP3

    SDCC : mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 3.2.0 #8008 (Jul 6 2012) (MINGW32)

    SDCC 3.2.0 gave the same result as 3.2.0a

    The defect is probably caused by compilation of a long function. I can provide function which makes the defect, but it is not a short one.

    Arnost Vecerka

     
  • Borut Ražem
    Borut Ražem
    2012-07-16

    Please attach the source file to this bug report.

    You didn't provide the requested output of compilation with -V option, but I assume that sdcc dies while executing the c++ code. We can't help you if we don't know how to reproduce the problem, that why we need the source file.

    There is no target specified in "parameters for compilation" (-m option), so it is (the default) mcs51?

    Borut

     
  • Arnost Vecerka
    Arnost Vecerka
    2012-07-17

    Source file for the bug report

     
    Attachments
  • Arnost Vecerka
    Arnost Vecerka
    2012-07-17

    I have uploaded source with one of the functions which caused problems during compilation.

    Target is MCS51.

    Arnost Vecerka

     
  • The issue canbe reproduced on other systems, such as Debian GNU/Linux. It seems we recurse infinitely into add_vertices_to_tree_decomposition() eating up all available memory for the stack.

    Philipp