Opened 9 years ago

Closed 9 years ago

#8700 closed Bugs (invalid)

multiprecision : Trying to cast to unsigned from cpp_int > 19 bits causes crash

Reported by: danq@… Owned by: John Maddock
Milestone: To Be Determined Component: multiprecision
Version: Boost 1.53.0 Severity: Showstopper
Keywords: crash cast multiprecision dump Cc:

Description

The code segment below shows an iteration through a list of fields. Each field will be filled with a sub-set of the cpp_int number.

If the cpp_int number is 20-bits or larger, the second line of the 'for' loop (where the cast to unsigned occurs) crashes bit-time.

When I comment out the cast, the code works file. If I reduce the size of the cpp_int 'i_addr' to 19 bits or less, it works fine.

20 bits or more causes a complete crash.

Ticket #8423 comments about a similar crash and that it was fixed for the next release. I was unable to find the fix. Note that in that example, the 32-bit value crashes while the 16-bit one does not.

Very similar to my case, so I suspect it is the same bug.

Can someone please confirm this?

Mingw 10.2 - GCC 4.8.1 - Boost 1.53.0 - FreeType 2.4.12, libogg 1.3.1, PCRE 8.33, pngcrush 1.7.60.

-----------------------------------------------------------

typedef boost :: multiprecision :: cpp_int Bit_Reg ;

Bit_Reg i_addr ; This is incremented elsewhere, but used in this loop

for (auto * i_field : table->i_field_list) {

Bit_Reg i_value = i_addr >> i_field->bits.lsb ;

i_field->value = i_value.template convert_to <unsigned> () ;

}

Change History (5)

comment:1 by John Maddock, 9 years ago

Can you provide a self-contained test case please? Note that the beta for 1.54 is out now, so it might be easiest for you to test against that?

comment:2 by danq@…, 9 years ago

I created a stripped-down test case, but it does not fail. No matter how large a count, the conversion works. Sigh...

I'm not sure how to go about integrating 1.54 into my toolset. I am using MinGW 10.2 distribution (a simple unzip and copy to destination folder type install).

One thought that just occurred to me is that the run-time stack probably increases as the cpp_int size increases (confirm?). Perhaps what is happening in my application code is the stack is heavily used and overflows somehow when I increases the bit size to 20 bits.

This might explain why the test case works. It has minimal stack requirements.

A side note (may be related):

This:

Bit_Reg i_value = i_addr >> i_field->bits.lsb ;

i_field->value = i_value.template convert_to <unsigned> () ;

Compiles while this:

i_field->value = static_cast <unsigned> (i_addr >> i_field->bits.lsb) ;

does not.

However, this:

Bit_Reg i_value = i_addr >> i_field->bits.lsb ;

i_field->value = static_cast <unsigned> (i_value) ;

works.

It seems that if I try to pass a temporary to the static_cast operator, the compiler complains.

I noticed this while trying to create a test case. Note: either method still fails when I reach 20 bits.

May or may not be related to the problem I am seeing.

Suggestions on how to install 1.54 beta into my (simple) Mingw environment?

Cheers!

Dan

comment:3 by John Maddock, 9 years ago

Suggestions on how to install 1.54 beta into my (simple) Mingw environment?

Just unpack the zip and place it in your path - multiprecision is header only. If you need other Boost libs, the easiest way would be to temporarily rename boost/multiprecision in the 1.53 tree and then copy the version from 1.54 over to test.

BTW bit usage shouldn't effect stack usage in cpp_int. Have you run under gdb and/or looked up the error code to see if it's a stack overflow?

comment:4 by danq@…, 9 years ago

News: Last night, I significantly increased the size of the run-time stack and the problem went away. Since you mentioned that cpp_int does not effect stack usage, I suspect that somewhere else in my code, the stack was getting loaded and by sheer chance, wound up clobbering my cpp_int variable.

I will play with GDB to see if I can pinpoint the cause.

I will also take a look at 1.54 and try to reproduce the problem with that version.

Thanks!

Dan

comment:5 by John Maddock, 9 years ago

Resolution: invalid
Status: newclosed

Closing for now, please reopen if you confirm a Boost bug.

Note: See TracTickets for help on using tickets.