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

[Crash] Floating point exception on Ubuntu 24.01 #2507

Closed
smallSwed opened this issue Sep 4, 2024 · 2 comments · Fixed by #2508
Closed

[Crash] Floating point exception on Ubuntu 24.01 #2507

smallSwed opened this issue Sep 4, 2024 · 2 comments · Fixed by #2508

Comments

@smallSwed
Copy link

Describe the bug
Crash while running on Ubuntu 24.01.
(In docker with Ubuntu 22 works fine)

To Reproduce
Steps to reproduce the behavior:

  1. Pointer to a minimized application (ideally the source code for it and instructions on which toolchain it was built with).
  • minimal code example:
#include <iostream>
int main() {
        std::cout << "Hello, Dr Memory!\n";
        return 0;
}
  • to build with gcc (version: g++ (Ubuntu 11.4.0-9ubuntu1) 11.4.0 but the version does not matter really)
g++ -g -fno-inline -fno-omit-frame-pointer test.cpp      
  1. Precise command line for running the application and Exact output or incorrect behavior.
  • normal execution works:
~/drmemory » ./a.out                                                                                                                          
Hello, Dr Memory!
  • Running with drmemory crashes:
~/drmemory » ./DrMemory-Linux-2.6.0/bin64/drmemory -- ./a.out 
[1]    11598 floating point exception (core dumped)  ./DrMemory-Linux-2.6.0/bin64/drmemory -- ./a.out

Please also answer these questions drawn from https://drmemory.org/page_help.html#sec_narrow :

  • Does the problem go away when running in light mode (pass -light to Dr. Memory)?
    Same result: crash [1] 14484 floating point exception (core dumped) ./DrMemory-Linux-2.6.0/bin64/drmemory -light -- ./a.out
  • Does the problem go away when running with the options -leaks_only -no_count_leaks -no_track_allocs?
    Same result: crash [1] 14612 floating point exception (core dumped) ./DrMemory-Linux-2.6.0/bin64/drmemory -leaks_only -no_count_leaks -- ./a.out
  • Does the problem go away when running under plain DynamoRIO? Do this by running dynamorio/bin32/drrun -- <application and args> or dynamorio/bin64/drrun -- <application and args> depending on the bitwidth of your applicaiton. (Ignore warnings about "incomplete installation".)
    Yes.
./DrMemory-Linux-2.6.0/dynamorio/bin64/drrun -- ./a.out
Hello, Dr Memory!
  • What happens with the debug version of Dr. Memory and of its underlying engine DynamoRIO? Try this by passing -debug -dr_debug -pause_at_assert. Are any messages reported?
~/drmemory » ./DrMemory-Linux-2.6.0/bin64/drmemory -debug -dr_debug -pause_at_assert -- ./a.out
<Starting application /home/sok/drmemory/a.out (15208)>
<Initial options = -no_dynamic_options -logdir '/home/sok/drmemory/DrMemory-Linux-2.6.0/drmemory/logs/dynamorio' -client_lib '/home/sok/drmemory/DrMemory-Linux-2.6.0/bin64/debug/libdrmemorylib.so;0;`-pause_at_assert` -logdir `/home/sok/drmemory/DrMemory-Linux-2.6.0/drmemory/logs` -symcache_dir `/home/sok/drmemory/DrMemory-Linux-2.6.0/drmemory/logs/symcache` -resfile 15208 ' -client_lib64 '/home/sok/drmemory/DrMemory-Linux-2.6.0/bin64/debug/libdrmemorylib.so;0;`-pause_at_assert` -logdir `/home/sok/drmemory/DrMemory-Linux-2.6.0/drmemory/logs` -symcache_dir `/home/sok/drmemory/DrMemory-Linux-2.6.0/drmemory/logs/symcache` -resfile 15208 ' -code_api -stack_size 56K -signal_stack_size 32K -disable_traces -no_enable_traces -max_elide_jmp 0 -max_elide_call 0 -no_shared_traces -bb_ibl_targets -bb_single_restore_prefix -no_shared_trace_ibl_routine -no_enable_reset -no_reset_at_switch_to_os_at_vmm_limit -reset_at_vmm_percent_free_limit 0 -no_reset_at_vmm_full -reset_at_commit_free_limit 0B -reset_every_nth_pending 0 -vm_size 256M -early_inject -emulate_brk -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct >
[1]    15208 floating point exception (core dumped)  ./DrMemory-Linux-2.6.0/bin64/drmemory -debug -dr_debug -pause_at_assert --

Expected behavior
No crash happens.

Versions

  • What version of Dr. Memory are you using?
    Dr. Memory version 2.6.0 -- build 0
  • Does the latest build from
    https://drmemory.org/page_download.html#sec_latest_build solve the problem?
    No. (I'm using the latest build)
  • What operating system version are you running on? ("Windows 10" is not sufficient: give the release number.)
~/drmemory » neofetch                                                                                                                         sok@C-L-SOK
         _    sok@C-L-SOK
     ---(_)   -----------
 _/  ---  \   OS: Ubuntu 24.04.1 LTS x86_64
(_) |   |     Host: LENOVO LNVNB161216
  \  --- _/   Kernel: 6.8.0-41-generic
     ---(_)   Uptime: 1 hour, 18 mins
              Packages: 2179 (dpkg), 228 (nix-user), 51 (nix-default), 11 (snap)
              Shell: zsh 5.9
              Resolution: 1920x1080, 1920x1080
              DE: GNOME 46.0 (Wayland)
              WM: Mutter
              WM Theme: Adwaita
              Theme: Yaru-purple-dark [GTK2/3]
              Icons: Yaru-purple [GTK2/3]
              Terminal: tmux
              CPU: 11th Gen Intel i7-11800H (16) @ 4.600GHz
              GPU: NVIDIA GeForce RTX 3050 Mobile
              GPU: Intel TigerLake-H GT1 [UHD Graphics]


  • Is your application 32-bit or 64-bit?
    64 bit

Additional context
the crash dump:
coredump.zip

@derekbruening
Copy link
Contributor

This is likely DynamoRIO/dynamorio#5437

derekbruening added a commit that referenced this issue Sep 4, 2024
Updates DR to the latest to get private loader fixes for recent glibc
versions.

Issue: DynamoRIO/dynamorio#5437
Fixes #2507
@derekbruening
Copy link
Contributor

If this is indeed the cited DR problem it should be fixed in a new build from source. Going to create a new release package.

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