_uselocale() overwrites data over a variable allocated near 0

[shooshx]

In my main cpp file I have a global variable g_ctrl which for some reason is allocated near the very beginning of the memory array. printing its address using

 printf("GCTRL  %p\n", &g_ctrl)

shows

GCTRL 0x40

Other global variables are not allocated such low addresses, only this one, I'm not sure why.
At some point pretty early in the program _uselocale() from some operator<< This function does _pthread_self() which returns 0 always, adds 176 to it and stores some value there. 0+176 just happens to fall on the capacity member of some std::vector in g_ctrl and from there it just goes downhill.

This is probably not relevant but I started noticing this only after compiling with -D_LIBCPP_DEBUG=0 which probably changed the layout of my objects abit and caused this to start happening. g_ctrl is allocated a low address even without _LIBCPP_DEBUG=0

I'm using 1.35.0

[kripken]

Sounds like a pthreads bug. I know @juj added some fields to the main struct that self is getting. Perhaps something's wrong there?

Any chance you have a standalone testcase, @shooshx?

[shooshx]

Minimal recreation:

#include <stdio.h>
#include <iostream>

class XCtrl
{
public:
    double m_d = 0.0;
    char buf[160];
    int x = 0;
};

XCtrl g_inst;

extern "C" { 

int main()
{
    printf("XXXXX %p %p   %d %d\n", &g_inst, &g_inst.x, sizeof(g_inst), g_inst.x );
    std::cout << &g_inst; // trigger the problem

    printf("XXXXX %d\n", g_inst.x); // see the result
    return 0;
}

}

compile with

em++ -g3 -O0 -std=c++11 --memory-init-file 0 tbug.cpp  -o js_main.html -s EXPORTED_FUNCTIONS="['_main']

and run the resulting js_main.html
for me this prints:

XXXXX 0x8 0xb0   176 0
0x8XXXXX 5267464

the last printf prints a value that was inserted to g_inst.x by _uselocale() that's called somewhere in the operator<<(void*)

The only thing that's actually needed in XCtrl is the one double. all the rest is just for exemplifying the problem. My guess is that it has something to do with the 8-alignment of the class that messes up it's allocation in memory.

>em++ --version
emcc (Emscripten gcc/clang-like replacement) 1.35.0 ((unknown revision))

[kripken]

Strange, on 1.36.5 the testcase builds with warnings

warning: unresolved symbol: _ZNSt3__213basic_ostreamIcNS_11char_traitsIcEEElsEPKv
warning: unresolved symbol: _ZNSt3__24coutE

Those are almost the symbols we expect, except for the 2 which should be 1: std::__2::basic_ostream<char, std::__2::char_traits<char> >::operator<<(void const*). Not sure what's going on here, the testcase looks pretty simple.

And running fails on missing those functions.

[hackcasual]

On 1.37.1

#include <iostream> 
#include <vector>

using namespace std;

void print_some_nums(vector < double > nums) {
  for (auto val: nums)
    cout << val << endl;
}

int main(int argc, char * argv[]) {
  print_some_nums({
    10,
    -20,
    40,
    -25,
    65.5,
    -200,
    0,
    30,
    0,
    0,
    10,
    -20,
    40,
    0,
    0,
    0,
    10,
    -20,
    40,
    -25,
    65.5,
    -200,
    0,
    30
  });
  return 0;
}

Compiled with em++ test.cpp -Oz -o test.js --profiling-funcs -s EVAL_CTORS=0 -std=c++11

Generates the following output:

10
-20
40
-25
65.5
-200
0
30
0
0
10
-20
40
0
0
0
10
-20
40
-25
65.5
-200
8.10663e-320 <--- Not 0.
30

The issue appears to be pthread_self always returning 0, so anything using that to store associated thread information will overwrite early parts of memory

[jgravelle-google]

#4813 has a fix for this

( cce0512 and db9ce62 )

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.