Ilya, could you help me with this too, please?

Hi, sure, I'll take a look. This one seems a bit more complex, since, unlike the previous one, I don't seem to be able to reproduce it with the s390x-on-s390x emulation (I tried `qemu-s390x ./lcalsCRaw --benchmark_format=json`).
I will still run trace diffing overnight and will try on x86_64 tomorrow, but, just in case, could you please attach your lcalsCRaw binary and the corresponding core dump?

Also, is there something related in the output of "dmesg" ? ... if a program really crashes, you sometimes get some valuable information there...

In the meantime I could reproduce this with qemu-s390x running on x86_64. Here is the backtrace:

#0  0x0000004000c1fd0a in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x0000004000bcccb0 in raise () from /lib64/libc.so.6
#2  0x0000004000bad384 in abort () from /lib64/libc.so.6
#3  0x00000040009064d4 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6
#4  0x0000004000903ade in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6
#5  0x0000004000903b68 in std::terminate() () from /lib64/libstdc++.so.6
#6  0x0000004000903e76 in __cxa_throw () from /lib64/libstdc++.so.6
#7  0x0000004000938420 in std::__throw_out_of_range_fmt(char const*, ...) () from /lib64/libstdc++.so.6
#8  0x000000000108f894 in benchmark::CPUInfo::CPUInfo() ()
#9  0x000000000108d51c in benchmark::CPUInfo::Get() ()
#10 0x0000000001087514 in benchmark::BenchmarkReporter::Context::Context() ()
#11 0x0000000001036732 in benchmark::RunSpecifiedBenchmarks(benchmark::BenchmarkReporter*, benchmark::BenchmarkReporter*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
#12 0x0000000001036158 in benchmark::RunSpecifiedBenchmarks() ()
#13 0x0000000001007956 in main ()

This seems to be a logic bug. I've extracted the following snippet from the benchmark:

#include <fstream>
#include <iostream>
#include <cstdlib>
int main() {
  int NumCPUs = 0;
  int MaxID = -1;
  std::ifstream f("/proc/cpuinfo");
  if (!f.is_open()) {
    std::cerr << "failed to open /proc/cpuinfo\n";
    return -1;
  }
  const std::string Key = "processor";
  std::string ln;
  while (std::getline(f, ln)) {
    if (ln.empty()) continue;
    size_t SplitIdx = ln.find(':');
    std::string value;
#if defined(__s390__)
    // s390 has another format in /proc/cpuinfo
    // it needs to be parsed differently
    if (SplitIdx != std::string::npos) {
      std::cout << ln.size() << " " << ln << std::endl;
      value = ln.substr(Key.size() + 1, SplitIdx - Key.size() - 1);
    }
#else
    if (SplitIdx != std::string::npos) value = ln.substr(SplitIdx + 1);
#endif
    if (ln.size() >= Key.size() && ln.compare(0, Key.size(), Key) == 0) {
      NumCPUs++;
      if (!value.empty()) {
        int CurID = std::atoi(value.c_str());
        MaxID = std::max(CurID, MaxID);
      }
    }
  }
}

and it dies on the following input line from /proc/cpuinfo:

wp		: yes

(note that there are tabs in it). There are two problems here:

1) The parser in the benchmark is not resilient to malformed inputs.
2) qemu-user does not emulate /proc/cpuinfo on s390x (but there is support for sparc, hppa and riscv, so it's possible to implement).

(In reply to Ilya Leoshkevich from comment #5)
> 1) The parser in the benchmark is not resilient to malformed inputs.

Oh! Good finding!

> 2) qemu-user does not emulate /proc/cpuinfo on s390x (but there is support
> for sparc, hppa and riscv, so it's possible to implement).

My intention reporting this bug was to guarantee there were no instructions being executed wrongly.
You've just proved this is not happening and I'm happy with it.

With that said, I'm OK if this bug is closed as NOTABUG.
I'll leave for you (Ilya and the qemu packagers on Fedora) to decide what is the best course of action here.

(In reply to Thomas Huth from comment #3)
> Also, is there something related in the output of "dmesg" ? ... if a program
> really crashes, you sometimes get some valuable information there...

Thomas, I didn't notice any related output in dmesg.
However, the coredump is being generated, but the output is from qemu-s390x-static and is not very helpful to investigate the issue.

(In reply to Tulio Magno Quites Machado Filho from comment #7)
> Thomas, I didn't notice any related output in dmesg.
> However, the coredump is being generated, but the output is from
> qemu-s390x-static and is not very helpful to investigate the issue.

Ah, sorry, never mind, I did not read your description close enough. I thought you were running with full system emulation (qemu-system-s390x), but you're using "userspace" emulation (qemu-s390x) instead. My comment only made sense for qemu-system-s390x - with qemu-s390x you of course do not get any useful output in the "dmesg" of the host kernel. Sorry for the confusion.

I've posted https://lore.kernel.org/qemu-devel/20230601162541.689621-1-iii@linux.ibm.com/ for the cpuinfo issue, but with that fix one more failure remains (it was distinct to begin with):

/tmp/tmp.nUUFsR5GwP/tools/timeit-target --limit-core 0 --limit-cpu 7200 --timeout 7200 --limit-file-size 104857600 --limit-rss-size 838860800 --append-exitstatus --redirect-output /tmp/tmp.nUUFsR5GwP/MultiSource/Benchmarks/MiBench/automotive-basicmath/Output/automotive-basicmath.test.out --redirect-input /dev/null --chdir /tmp/tmp.nUUFsR5GwP/MultiSource/Benchmarks/MiBench/automotive-basicmath --summary /tmp/tmp.nUUFsR5GwP/MultiSource/Benchmarks/MiBench/automotive-basicmath/Output/automotive-basicmath.test.time /tmp/tmp.nUUFsR5GwP/MultiSource/Benchmarks/MiBench/automotive-basicmath/automotive-basicmath
/tmp/tmp.nUUFsR5GwP/tools/HashProgramOutput.sh /tmp/tmp.nUUFsR5GwP/MultiSource/Benchmarks/MiBench/automotive-basicmath/Output/automotive-basicmath.test.out
/tmp/tmp.nUUFsR5GwP/tools/fpcmp-target /tmp/tmp.nUUFsR5GwP/MultiSource/Benchmarks/MiBench/automotive-basicmath/Output/automotive-basicmath.test.out /tmp/tmp.nUUFsR5GwP/MultiSource/Benchmarks/MiBench/automotive-basicmath/automotive-basicmath.reference_output

/tmp/tmp.nUUFsR5GwP/tools/fpcmp-target: Comparison failed, textual difference between 'a' and 'e'

I will have a look at it a bit later.

That one was another broken insn after all: https://lore.kernel.org/qemu-devel/20230601223027.795501-1-iii@linux.ibm.com/
Not the testsuite is finally green.

Assigning to Ilya and setting status.  Note that there's no action which needs
to be taken here.  When we rebase qemu and include the fix we can just close
this bug.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.