Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

version 1.4.1 is broken on s390x #711

Closed
gladk opened this issue Oct 20, 2018 · 11 comments · Fixed by #712
Closed

version 1.4.1 is broken on s390x #711

gladk opened this issue Oct 20, 2018 · 11 comments · Fixed by #712

Comments

@gladk
Copy link
Contributor

gladk commented Oct 20, 2018

Almost all unit tests are failing on s390x with the new 1.4.1 version of benchmark. I executed the basic_test in gdb. And backtrace after the throwing an exception is here:

Catchpoint 1 (exception thrown), 0x000003fffdc27860 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x10001a7c8, tinfo=0x3fffdd2e920 <typeinfo for std::invalid_argument>, dest=0x3fffdc3e8e0 <std::invalid_argument::~invalid_argument()>) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:78 78 ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc: No such file or directory. #0 0x000003fffdc27860 in __cxxabiv1::__cxa_throw (obj=obj@entry=0x10001a7c8, tinfo=0x3fffdd2e920 <typeinfo for std::invalid_argument>, dest=0x3fffdc3e8e0 <std::invalid_argument::~invalid_argument()>) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:78 #1 0x000003fffdc548cc in std::__throw_invalid_argument (__s=__s@entry=0x3fffdf4bf9e "stoi") at ../../../../../src/libstdc++-v3/src/c++11/functexcept.cc:74 #2 0x000003fffdf47d34 in __gnu_cxx::__stoa<long, int, char, int> (__idx=0x0, __str=0x10001a650 " version = FF, identification = 01F467, machine = 2964", __name=0x3fffdf4bf9e "stoi", __convf=<optimized out>) at /usr/include/c++/8/bits/char_traits.h:320 #3 std::__cxx11::stoi (__base=10, __idx=0x0, __str=" version = FF, identification = 01F467, machine = 2964") at /usr/include/c++/8/bits/basic_string.h:6402 #4 benchmark::(anonymous namespace)::GetNumCPUs () at ./src/sysinfo.cc:411 #5 0x000003fffdf4883e in benchmark::CPUInfo::CPUInfo (this=0x1000183d0) at ./src/sysinfo.cc:581 #6 0x000003fffdf488f8 in benchmark::CPUInfo::Get () at ./src/sysinfo.cc:577 #7 0x000003fffdf2006e in benchmark::internal::Benchmark::ThreadPerCpu (this=0x100018250) at ./src/benchmark_register.cc:435 #8 0x0000000100001510 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ./include/benchmark/benchmark.h:940 #9 _GLOBAL__sub_I__Z8BM_emptyRN9benchmark5StateE () at ./test/basic_test.cc:136 #10 0x0000000100002508 in __libc_csu_init () #11 0x000003fffd823ac8 in __libc_start_main (main=0x100001428 <main(int, char**)>, argc=<optimized out>, argv=0x3fffffff588, init=0x1000024b0 <__libc_csu_init>, fini=0x100002520 <__libc_csu_fini>, rtld_fini=0x3fffdf90428 <_dl_fini>, stack_end=0x3fffffff4d0) at libc-start.c:266 #12 0x0000000100001b74 in _start () at ./include/benchmark/benchmark.h:940

The full backtrace is attached.

Thanks
gdb.txt

@LebedevRI
Copy link
Collaborator

I guess #481 didn't quite get fixed (:

@gladk
Copy link
Contributor Author

gladk commented Oct 20, 2018

No it was fixed for the previous version. But is broken in 1.4.1

@LebedevRI
Copy link
Collaborator

I'm going to guess #596 is related.

@gladk
Copy link
Contributor Author

gladk commented Oct 20, 2018

OK, I will check with the latest version in git and report.

@LebedevRI
Copy link
Collaborator

No, as in, i would have guessed, that refactoring might have broken it?
It would be good to get that backtrace with -O0.

@LebedevRI
Copy link
Collaborator

My personal guess is that that value is bad, thus it throws, and we don't catch it.

@gladk
Copy link
Contributor Author

gladk commented Oct 20, 2018

gdb.txt

I have attached the backtrace with -O0 and the current git version. As you pointed, the problem is in frame 9 probably:

value = " version = FF, identification = 01F467, machine = 2964"

@gladk
Copy link
Contributor Author

gladk commented Oct 20, 2018

Just some more info about the processors on this machine.

cat /proc/cpuinfo
vendor_id       : IBM/S390
# processors    : 2
bogomips per cpu: 9057.00
max thread id   : 0
features        : esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx sie
cache0          : level=1 type=Data scope=Private size=128K line_size=256 associativity=8
cache1          : level=1 type=Instruction scope=Private size=96K line_size=256 associativity=6
cache2          : level=2 type=Data scope=Private size=2048K line_size=256 associativity=8
cache3          : level=2 type=Instruction scope=Private size=2048K line_size=256 associativity=8
cache4          : level=3 type=Unified scope=Shared size=65536K line_size=256 associativity=16
cache5          : level=4 type=Unified scope=Shared size=491520K line_size=256 associativity=30
processor 0: version = FF,  identification = 01F467,  machine = 2964
processor 1: version = FF,  identification = 01F467,  machine = 2964

cpu number      : 0
cpu MHz dynamic : 5000
cpu MHz static  : 5000

cpu number      : 1
cpu MHz dynamic : 5000
cpu MHz static  : 5000

@LebedevRI
Copy link
Collaborator

LebedevRI commented Oct 20, 2018

It is looking for the pattern like

processor       : 0<newline>
...
processor       : 1<newline>
...
...
processor       : n-1<newline>

So for that arch, it should either simply use # processors : 2,
or use the number right after processor and before :.

@gladk
Copy link
Contributor Author

gladk commented Oct 20, 2018

If I hardocode the line 411 in src/sysinfo.cc, tests are passing. So the problem is that s390x machines are having another cpuinfo-output.

@gladk
Copy link
Contributor Author

gladk commented Oct 20, 2018

OK, @LebedevRI I will try to provide a patch. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants