Bug 26145 - Internal error showing _M_local_word in ostream
Summary: Internal error showing _M_local_word in ostream
Status: RESOLVED DUPLICATE of bug 21356
Alias: None
Product: gdb
Classification: Unclassified
Component: c++ (show other bugs)
Version: 8.3
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-21 09:14 UTC by Pierre Abbat
Modified: 2024-06-28 18:45 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Abbat 2020-06-21 09:14:51 UTC
I'm debugging a program I'm writing, which has what appears to be a concurrency bug. The stack trace is:

(gdb) where
#0  __memmove_avx_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:321
#1  0x00007ffff7e4a298 in std::char_traits<char>::copy (__n=4, 
    __s2=0x7ffff71a1900 "\377\177", __s1=<optimized out>)
    at /build/gcc-9-NSfpi_/gcc-9-9.2.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/char_traits.h:365
#2  std::basic_streambuf<char, std::char_traits<char> >::xsputn (
    this=0x44f940 <octStore+24>, __s=0x7ffff71a1900 "\377\177", __n=4)
    at /build/gcc-9-NSfpi_/gcc-9-9.2.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/streambuf.tcc:90
#3  0x00007ffff7e38a37 in std::basic_streambuf<char, std::char_traits<char> >::sputn (__n=4, __s=<optimized out>, this=<optimized out>)
    at /build/gcc-9-NSfpi_/gcc-9-9.2.1/build/x86_64-linux-gnu/libstdc++-v3/include/streambuf:457
#4  std::ostream::_M_write (__n=4, __s=<optimized out>, 
    this=0x44f938 <octStore+16>)
    at /build/gcc-9-NSfpi_/gcc-9-9.2.1/build/x86_64-linux-gnu/libstdc++-v3/include/ostream:319
#5  std::ostream::write (this=0x44f938 <octStore+16>, 
    __s=0x7ffff71a1900 "\377\177", __n=4)
    at /build/gcc-9-NSfpi_/gcc-9-9.2.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:196
#6  0x000000000040a6dd in writelefloat (file=..., f=4.59163468e-41)
    at /home/phma/src/wolkenbase/binio.cpp:198
#7  0x000000000040e6dd in LasPoint::write (this=0x518a20, file=...)
    at /home/phma/src/wolkenbase/las.cpp:108
#8  0x0000000000411dfd in OctBlock::write (this=0x49a098)
    at /home/phma/src/wolkenbase/octree.cpp:160
#9  0x0000000000412067 in OctBlock::flush (this=0x49a098)
    at /home/phma/src/wolkenbase/octree.cpp:199
#10 0x0000000000412bc4 in OctStore::getBlock (this=0x44f928 <octStore>, 
    block=23, mustExist=false) at /home/phma/src/wolkenbase/octree.cpp:320
#11 0x000000000041274e in OctStore::getBlock (this=0x44f928 <octStore>, 
    key=...) at /home/phma/src/wolkenbase/octree.cpp:337
#12 0x000000000041247e in OctStore::operator[] (this=0x44f928 <octStore>, 
    key=...) at /home/phma/src/wolkenbase/octree.cpp:260
#13 0x000000000042028f in WolkenThread::operator() (this=0x4a2c68, thread=1)
    at /home/phma/src/wolkenbase/threads.cpp:301

writelefloat, which is also in Bezitopo and PerfectTIN, is simply this:

void writebefloat(std::ostream &file,float f)
{
  char buf[4];
  *(float *)buf=f;
#ifndef BIGENDIAN
  endianflip(buf,4);
#endif
  file.write(buf,4);
}

So I do "frame 6", "print buf" (which says "\377\177\000" ­— the number is 0x00007fff) and "print file", which fails as follows:

$2 = (std::ostream &) @0x44f938: {<std::basic_ios<char, std::char_traits<char> >> = {<std::ios_base> = {
      _vptr.ios_base = 0x7ffff7ee7248 <vtable for std::basic_fstream<char, std::char_traits<char> >+104>, static boolalpha = std::_S_boolalpha, 
      static dec = std::_S_dec, static fixed = std::_S_fixed, 
      static hex = std::_S_hex, static internal = std::_S_internal, 
      static left = std::_S_left, static oct = std::_S_oct, 
      static right = std::_S_right, static scientific = std::_S_scientific, 
      static showbase = std::_S_showbase, 
      static showpoint = std::_S_showpoint, static showpos = std::_S_showpos, 
      static skipws = std::_S_skipws, static unitbuf = std::_S_unitbuf, 
      static uppercase = std::_S_uppercase, 
      static adjustfield = std::_S_adjustfield, 
      static basefield = std::_S_basefield, 
      static floatfield = std::_S_floatfield, static badbit = std::_S_badbit, 
      static eofbit = std::_S_eofbit, static failbit = std::_S_failbit, 
      static goodbit = std::_S_goodbit, static app = std::_S_app, 
      static ate = std::_S_ate, static binary = std::_S_bin, 
      static in = std::_S_in, static out = std::_S_out, 
      static trunc = std::_S_trunc, static beg = std::_S_beg, 
      static cur = std::_S_cur, static end = std::_S_end, _M_precision = 6, 
      _M_width = 0, _M_flags = 0, _M_exception = std::_S_goodbit, 
      _M_streambuf_state = 33, _M_callbacks = 0x206e776f6e6b6e55, 
--Type <RET> for more, q to quit, c to continue without paging--
      _M_word_zero = {_M_pword = 0x3420646165726874, _M_iword = 46}, 
      _M_local_word = {
/build/gdb-6oQbwX/gdb-8.3/gdb/value.c:847: internal-error: bool value_contents_bits_eq(const value*, int, const value*, int, int): Assertion `offset1 + length <= TYPE_LENGTH (val1->enclosing_type) * TARGET_CHAR_BIT' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

Here is file dumped in hex:

(gdb) x/68xw &file
0x44f938 <octStore+16>:  0xf7ee7220 0x00007fff 0xf7ee6e88 0x00007fff
0x44f948 <octStore+32>:  0x004a0570 0x00000000 0x004a0570 0x00000000
0x44f958 <octStore+48>:  0x004a0570 0x00000000 0x00000000 0x00000000
0x44f968 <octStore+64>:  0x00000000 0x00000000 0x00000000 0x00000000
0x44f978 <octStore+80>:  0xf7eefc20 0x00007fff 0x00000000 0x00000000
0x44f988 <octStore+96>:  0x00000000 0x00000000 0x00000000 0x00000000
0x44f998 <octStore+112>: 0x00000000 0x00000000 0x00000000 0x00000000
0x44f9a8 <octStore+128>: 0x004a0380 0x00000000 0x00000001 0x00000000
0x44f9b8 <octStore+144>: 0x0000003c 0x00000000 0x00000000 0x00000000
0x44f9c8 <octStore+160>: 0x00000000 0x00000000 0x00000000 0x00000000
0x44f9d8 <octStore+176>: 0x004a0570 0x00000000 0x00002000 0x00000000
0x44f9e8 <octStore+192>: 0x00000001 0x00000000 0x00000000 0x00000000
0x44f9f8 <octStore+208>: 0x00000000 0x00000000 0x00000000 0x00000000
0x44fa08 <octStore+224>: 0xf7eef5b0 0x00007fff 0x00000000 0x00000000
0x44fa18 <octStore+240>: 0x00000000 0x00000000 0x00000000 0x00000000
0x44fa28 <octStore+256>: 0x00000000 0x00000000 0xf7ee7248 0x00007fff
0x44fa38 <octStore+272>: 0x00000006 0x00000000 0x00000000 0x00000000

file is actually an fstream, but is passed to writebefloat as an ostream. There are two worker threads, and they have a mutex so that only one can read or write the file at once.
Comment 1 Hannes Domani 2024-06-28 18:45:31 UTC
Dup.

*** This bug has been marked as a duplicate of bug 21356 ***