Package Details: rr 5.8.0-3

Git Clone URL: https://aur.archlinux.org/rr.git (read-only, click to copy)
Package Base: rr
Description: Record and Replay framework: lightweight recording and deterministic debugging
Upstream URL: http://rr-project.org/
Licenses: custom
Submitter: dequis
Maintainer: codyps (zrhoffman, SandaruKasa, DarkShadow44, giordano)
Last Packager: SandaruKasa
Votes: 72
Popularity: 1.33
First Submitted: 2015-08-24 23:26 (UTC)
Last Updated: 2024-10-14 21:11 (UTC)

Dependencies (13)

Required by (0)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

angelv commented on 2023-02-20 21:47 (UTC)

@codyps thanks, it works fine.

codyps commented on 2023-02-20 16:59 (UTC)

@angelv: I've added a patch for that issue, using what upstream rr's patch: https://github.com/rr-debugger/rr/commit/2979c60ef8bbf7c940afd90172ddc5d8863f766e

angelv commented on 2023-02-20 09:45 (UTC) (edited on 2023-02-20 09:46 (UTC) by angelv)

Related to my previous comment, a simple line swap in record_syscall.cc fixes the problem.

rr-5.6.0/src$ diff record_syscall.cc record_syscall.cc~ 
1454d1453
<     uint32_t data;
1455a1455
>     uint32_t data;

angelv commented on 2023-02-20 09:22 (UTC) (edited on 2023-02-20 09:46 (UTC) by angelv)

In a recently updated system I cannot get rr to build. I get errors like:

/usr/include/linux/ethtool.h:823:17: error: flexible array member ‘ethtool_sset_info::data’ not at end of ‘struct rr::get_ethtool_gstrings_arch<X86Arch>(RecordTask*)::SingleStringSet’

chipbuster commented on 2022-02-09 20:53 (UTC) (edited on 2022-02-09 20:54 (UTC) by chipbuster)

I'm hitting a strange issue with this PKGBUILD that is almost certainly partially caused by configuration on my end, but I don't understand what's going wrong.

I can build and install this package just fine. When I try to record with the version that's been installed into /usr/bin, I get an assertion failure and crash.

However, when I record with the version that's in pkg in the build directory, everything works fine. Even more mysteriously, when I tried to make a Docker to reproduce the bug, both the rr at /usr/bin/rr and the one within pkg can successfully record a trace! (Also, when running makepkg/pacman -U in Docker, rr gets installed into /usr/sbin for reasons that I don't understand).

Does anyone have any clue what might be going on here, or how I can further narrow down what the root cause of this is?

vlovich commented on 2021-03-09 23:24 (UTC)

Gotcha. That makes sense. I was just comparing against rr-git which used -DCMAKE_BUILD_TYPE=Release.

codyps commented on 2021-03-09 22:37 (UTC)

@vlovich: I could have sworn that build type was suggested at some point as the right way to disable flags getting added, but you're right that there doesn't appear to be any documentation on it to speak of.

Based on https://wiki.archlinux.org/index.php/CMake_package_guidelines, it looks like using CMAKE_BUILD_TYPE=None is really the intention (well, maybe. cmake projects are complicated).

In general, Release and RelWithDebInfo aren't what we want to package though: we expect the cflags/etc to be provided via the user's makepkg.conf (or similar) rather than setting debuginfo/opt-level flags in the PKGBUILD directly.

vlovich commented on 2021-03-09 22:17 (UTC)

I see CMAKE_BUILD_TYPE=plain in the PKGBUILD for this but shouldn't that be Release or RelWithDebInfo? I'm not familiar with the "plain" build type & I don't see that referenced anywhere in the upstream repo.

konsonanz commented on 2020-11-16 22:35 (UTC)

@codyps: Thanks for the quick fix! You're right, I'm using clang and libc++ for builds against the host toolchain. A build in a clean and default chroot worked without problems.

Regarding the pastebin issue, seems like something went wrong there as I also can't (re-)apply the diff there due to some corruption error. Will take better care/test beforehand next time.

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »