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: | 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 , 9 years ago
comment:2 by , 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 , 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 , 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 , 9 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Closing for now, please reopen if you confirm a Boost bug.
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?