Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #89
Closed
Open
Issue created Nov 27, 2014 by Derek Bruening@derekbrueningContributor

ASSERT (r94 ls) CURIOSITY(ma->start + ma->os_data.alignment == base) at os.c:3549

From [email protected] on March 20, 2009 14:51:09

DynamoRIO crash on debug version OS: ubuntu 8.10 DR: revision 94 What steps will reproduce the problem? 1. /Workspace/DynamoRIO/dynamorio-bld/exports/bin32/drdeploy -debug ls What is the expected output? What do you see instead? zhaoqin@Ubuntu-8:/Workspace/EDDI/test$ ~/Workspace/DynamoRIO/dynamorio-bld/exports/bin32/drdeploy -debug ls <Starting application ls (10774)> <Initial options = > start + ma->os_data.alignment == base in file /home/zhaoqin/Workspace/DynamoRIO/dynamorio-dev/core/linux/os.c line 3551 version 1.3.2, build 18

0xbfb79038 0xb7fb8246 0xbfb790a8 0xb7fba56b 0xbfb79138 0xb7f3ced5 0xbfb79208 0xb7e65d8f 0xbfb794a8 0xb7dec58c 0xbfb799a8 0xb806bae4 0xbfb799d8 0xb806bc14 0xbfb79a18 0xb805e82f> <stackdump: glibc backtrace:> /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdynamorio.so(glibc_stackdump+0x30)[0xb7fcd2d1] /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdynamorio.so(stackdump+0xb8)[0xb7fcd3a6] /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdynamorio.so(os_dump_core+0xec)[0xb7fc4350] /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdynamorio.so(report_dynamorio_problem+0x50d)[0xb7ebcfca] /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdynamorio.so[0xb7fb8246] /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdynamorio.so(find_executable_vm_areas+0xc2)[0xb7fba56b] /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdynamorio.so(vm_areas_init+0x4b9)[0xb7f3ced5] /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdynamorio.so(dynamorio_app_init+0x149c1)[0xb7e65d8f] /home/zhaoqin/Workspace/DynamoRIO/dynamorio-bld/exports/lib32/debug/libdrpreload.so(_init+0xd2)[0xb7dec58c] /lib/ld-linux.so.2[0xb806bae4] /lib/ld-linux.so.2[0xb806bc14] /lib/ld-linux.so.2[0xb805e82f] <Application ls (10774). Internal Error Internal DynamoRIO Error: /home/zhaoqin/Workspace/DynamoRIO/dynamorio-dev/core/linux/signal.c:2791 syscall_signal || in_fcache(pc) (Error occurred @0 frags) version 1.3.2, build 18

0x18d23ce8 0xb7ebba95 0x18d23e38 0xb7fc9928 0x18d23fb8 0xb7f9ed6d 0xbfb78e28 0xb7fcd415 0xbfb78f98 0xb7fc4350 0xbfb78fc8 0xb7ebcfca 0xbfb79038 0xb7fb8246 0xbfb790a8 0xb7fba56b 0xbfb79138 0xb7f3ced5 0xbfb79208 0xb7e65d8f 0xbfb794a8 0xb7dec58c> frame ptr 0x18d23c48 => parent 0x18d23c78, ret = 0xb7fc4385 frame ptr 0x18d23c78 => parent 0x18d23ce8, ret = 0xb7ebcfca frame ptr 0x18d23ce8 => parent 0x18d23e38, ret = 0xb7ebba95 frame ptr 0x18d23e38 => parent 0x18d23fb8, ret = 0xb7fc9928 frame ptr 0x18d23fb8 => parent 0xbfb78e28, ret = 0xb7f9ed6d frame ptr 0xbfb78e28 => parent 0xbfb78f98, ret = 0xb7fcd415 frame ptr 0xbfb78f98 => parent 0xbfb78fc8, ret = 0xb7fc4350 frame ptr 0xbfb78fc8 => parent 0xbfb79038, ret = 0xb7ebcfca frame ptr 0xbfb79038 => parent 0xbfb790a8, ret = 0xb7fb8246 frame ptr 0xbfb790a8 => parent 0xbfb79138, ret = 0xb7fba56b frame ptr 0xbfb79138 => parent 0xbfb79208, ret = 0xb7f3ced5 frame ptr 0xbfb79208 => parent 0xbfb794a8, ret = 0xb7e65d8f frame ptr 0xbfb794a8 => parent 0xbfb799a8, ret = 0xb7dec58c frame ptr 0xbfb799a8 => parent 0xbfb799d8, ret = 0xb806bae4 frame ptr 0xbfb799d8 => parent 0xbfb79a18, ret = 0xb806bc14 frame ptr 0xbfb79a18 => parent 0x00000000, ret = 0xb805e82f <Crashing the process deliberately for a core dump!> <core not found, trying core.10779> <ERROR: no core file found!> <-------------------------------------------> <Crashing the process deliberately for a core dump!> Segmentation fault

It seems never happens before, which might because I only run release version before.

The problem is caused in core/linux/os.c mmap_check_for_module_overlap(). When find_executable_vm_areas() reading memory maps from /proc, it reads vdso, and fail on ASSERT_CURIOSITY(ma->start + ma->os_data.alignment == base) at os.c:3549

b7fa3000-b7fbd000 r-xp 00000000 08:01 108679 /lib/ld-2.8.90.so b7fbd000-b7fbe000 r-xp b7fbd000 00:00 0 [vdso] b7fbe000-b7fbf000 r--p 0001a000 08:01 108679 /lib/ld-2.8.90.so b7fbf000-b7fc0000 rw-p 0001b000 08:01 108679 /lib/ld-2.8.90.so

In such case: ma->start is 0xb7fa3000 ma->os_data.alignment is 4096 base is b7fbd000.

the vdso seems has elf so header. So it pass the check of if (readable && is_elf_so_header(base, size)) at os.c:3536

FIX, only call mmap_check_for_module_overlap() after check if it is vdso.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=89

Assignee
Assign to
Time tracking