|
From: Mark W. <ma...@kl...> - 2023-02-03 10:53:00
|
Hi valgrind developers, Paul suggested that we should have a developer video chat again to discuss development issues. And I agree that would be a good thing to set some goals for the next release in April. We would like to meet on Friday February 10 at 16:00 UTC (17:00 CET, 11:00 EST). https://meet.jit.si/ValgrindDevMeeting Some issues we can discuss: - Pick a date for the April 3.21.0 release Critical bugs that are must fix? - Upstreaming risc-v - https://github.com/petrpavlu/valgrind-riscv64 - AVX512 status - https://bugs.kde.org/show_bug.cgi?id=383010 - loongarch - https://bugs.kde.org/show_bug.cgi?id=457504 - The macOS port status - do we have any users/developers? - https://bugs.kde.org/show_bug.cgi?id=433859 aligned and sized stuff. Do we have enough bits to track this efficiently? - Plugging into the new FORTIFY_SOURCE=3 support in glibc. valgrind memcheck should be able to show useful information about the memory block that triggered the fault. - Infrastructure stuff. We are still using the sourcefore mailinglist and the kde bugzilla. But our git repo and website are at sourceware. Should we migrate everything to sourceware? - Would that be a good point to switch from "master" to "main" for the main git branch name? We already largely avoid terms like black/whitelist and master/slave in the code and it would be a good transition towards more inclusive language as described in https://inclusivenaming.org/ These are all just suggestions. Please feel free to join and/or propose other topics, features or bugs to discuss. Cheers, Mark |
|
From: Floyd, P. <pj...@wa...> - 2023-02-09 17:24:52
|
On 03/02/2023 11:52, Mark Wielaard wrote: > Hi valgrind developers, > > - The macOS port status - do we have any users/developers? Been having a fairly long look at this. Will update on Friday. There has been a lot of noise about memory safety recently. https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://advocacy.consumerreports.org/wp-content/uploads/2023/01/Memory-Safety-Convening-Report-1-1.pdf And some responses from C++ (I don't follow C standards evolution so closely) https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2759r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2687r0.pdf If they do "fix" C and C++ we might be out of a job ;-) A+ Paul |
|
From: Louis B. <lou...@gm...> - 2023-02-09 19:29:32
|
On 03/02/2023 11:52, Mark Wielaard wrote: > Hi valgrind developers, > > - The macOS port status - do we have any users/developers? I was planning to join the meetup (like last year) but I won't be able to attend. I would be happy to support the port more directly (my mirror has x86 support for all macOS versions, with some caveats for some versions), how can I get more involved? On Thu, 9 Feb 2023 at 17:25, Floyd, Paul <pj...@wa...> wrote: > Been having a fairly long look at this. Will update on Friday. I would love to hear your thoughts Paul, you can message me directly if you want (or forward me any notes from the meetup if there are any). Thanks! Louis Brunner |
|
From: Paul F. <pj...@wa...> - 2023-02-09 21:32:41
|
On 09-02-23 20:29, Louis Brunner wrote: > I would love to hear your thoughts Paul, you can message me directly if > you want (or forward me any notes from the meetup if there are any). Thanks! Salut Louis No time like the present. Here are the main problems that I see. 1. The biggest problem. The dyld cache (dsc) since macOS 11 Big Sur. macOS no longer has physical files for the system libraries. They are loaded from a memory cache. That means no di_notify_mmap and that means no redirs, which greatly restricts the functionality of memcheck and massif and drd, helgrind and dhat don't work. Callgrind and cachegrind are a bit less impacted. lldb and gdb both have ways of getting round this. Remember that in their configuration there are two processes communicating via clunky ptrace. Since both will have loaded the systems libs lldb just uses reads everything from its own memory. I still only have a basic understanding of how that works. I also look briefly at gdb. The code looks a lot simpler - fairly flat C rather than several widely spread C++ classes. There are also a few tools that can extract files from the cache which might be enough for di_notify_mmap to read. The last big problem here is GPLv2. I believe that we can reuse code from gdb, but we can't reuse anything from llvm/lldb or Apple XNU. 2. Thread termination. Valgrind is using a mach message to kill threads that fall off the end. That no longer works (since macOS 10.14 I think) The thread continues to run and hits a panic. There's a comment in the code about using bsdthread_terminate instead. If I single step through the assembler the is indeed how threads die. There are two things that I need to see - how to get the arguments for bsdthread_terminate and are there any consequences on not cleaning up the pthread resources cleanly? 3. I was seeing an assert on all DRD runs, but I fixed that upstream yesterday 6e4eb0b674db465c9c332ec72b5c7f5202de7d71. 4. Apple ARM hardware. I haven't looked at this (I have an Intel macbook) so I can't estimate how much is missing. After that, quite a lot of smaller problems (a few hangs, some readdwarf errors quite a few varinfo diffs and quite a few more I haven't looked at). There may be more hidden behind the issues listed above. I don't know how many people (and more particularly developers) use older versions of macOS. macOS is the number 1 item in bugzilla, and there are frequent requests on stack overflow. I believe that Louis' port does get a fair amount of traffic from one of the two main macOS package systems. My feeling is that if we can get fixes for the first two then the port will be a lot more usable. A+ Paul |
|
From: Mark W. <ma...@kl...> - 2023-02-13 17:36:34
|
Hi valgrind developers, Thanks for those that could join. I didn't really take notes, so this is very brief. If I got something wrong, please feel free to correct. On Fri, 2023-02-03 at 11:52 +0100, Mark Wielaard wrote: > Paul suggested that we should have a developer video chat again to > discuss development issues. And I agree that would be a good thing to > set some goals for the next release in April. We would like to meet > on Friday February 10 at 16:00 UTC (17:00 CET, 11:00 EST). > > https://meet.jit.si/ValgrindDevMeeting > > Some issues we can discuss: > > - Pick a date for the April 3.21.0 release > Critical bugs that are must fix? We picked Friday April 14 for the RC and Friday April 28 for the final release. But we didn't designate any critical must fix bugs (yet?) > - Upstreaming risc-v - https://github.com/petrpavlu/valgrind-riscv64 Petr explained the current status, it is fairly far along, but probably won't make the next release. https://github.com/petrpavlu/valgrind-riscv64/blob/riscv64-linux/README.md Note that the gcc compile farm has riscv hardware now: https://cfarm.tetaneutral.net/machines/list/ In general valgrind developers can request access to these machines. https://cfarm.tetaneutral.net/users/new/ > - AVX512 status - https://bugs.kde.org/show_bug.cgi?id=383010 We lost contact with the Intel group that was working on this. There are still some issues with it. It needs someone with enough time to work on it. > - loongarch - https://bugs.kde.org/show_bug.cgi?id=457504 This is split in several small patches and the contributor is really responsive. We should split the patches in those that change the core code and those that are are just for the loongarch backend. The gcc compiler farm does have two (experimental) machines: https://cfarm.tetaneutral.net/news/37 > - The macOS port status - do we have any users/developers? There is an active fork: https://github.com/LouisBrunner/valgrind-macos > - https://bugs.kde.org/show_bug.cgi?id=433859 aligned and sized stuff. > Do we have enough bits to track this efficiently? This is for C23, which isn't standard yet. So it won't need to go in soon. Julian said that he often disables the alloc/free/new/delete matching because it gets confused with some c++ allocators (?). It wasn't clear if there is a good solution for that. > - Plugging into the new FORTIFY_SOURCE=3 support in glibc. valgrind > memcheck should be able to show useful information about the memory > block that triggered the fault. After the meeting Sam found a glibc bug describing the idea: https://sourceware.org/bugzilla/show_bug.cgi?id=20644 > - Infrastructure stuff. We are still using the sourcefore mailinglist > and the kde bugzilla. But our git repo and website are at > sourceware. Should we migrate everything to sourceware? It is all a little clunky not having everything in one place. But nobody seemed to look forward to having to migrate. Also do we need people's opt-in/out consent for moving subscriptions? > - Would that be a good point to switch from "master" to "main" for the > main git branch name? We already largely avoid terms like > black/whitelist and master/slave in the code and it would be a good > transition towards more inclusive language as described in > https://inclusivenaming.org/ We'll switch the default branch to main (with master being an alias) after the release. > These are all just suggestions. Please feel free to join and/or > propose other topics, features or bugs to discuss. We also briefly discussed: - https://bugs.kde.org/show_bug.cgi?id=402833 memcheck/tests/overlap testcase fails, memcpy seen as memmove The issue is if through ifuncs both memcpy and memmove point to the same address/function. It isn't clear whether there is a good solution (we probably need to recognize these functions before doing the ifunc resolving?). If not, maybe we should stop doing overlap checks for memcpy by default. - https://bugs.kde.org/show_bug.cgi?id=434057 Add stdio mode to valgrind's gdbserver This is something which Sasha and I have been working on so you can run a program under valgrind from gdb directly. Sasha will post a little overview of the current state. |
|
From: Paul F. <pj...@wa...> - 2023-02-27 22:41:48
|
On 13-02-23 18:36, Mark Wielaard wrote: > Hi valgrind developers, > >> Some issues we can discuss: >> >> - Pick a date for the April 3.21.0 release >> Critical bugs that are must fix? > > We picked Friday April 14 for the RC and Friday April 28 for the final > release. But we didn't designate any critical must fix bugs (yet?) Nothing critical, but always a lot of things that I'd like to get done by then. >> - loongarch - https://bugs.kde.org/show_bug.cgi?id=457504 > > This is split in several small patches and the contributor is really > responsive. We should split the patches in those that change the core > code and those that are are just for the loongarch backend. I had another look. There is a new signal, SISGSYS, and a lot of the syscall changes are due to not handling SA_RESTART. I don't yet understand why. >> - https://bugs.kde.org/show_bug.cgi?id=433859 aligned and sized stuff. >> Do we have enough bits to track this efficiently? > > This is for C23, which isn't standard yet. So it won't need to go in > soon. Julian said that he often disables the alloc/free/new/delete > matching because it gets confused with some c++ allocators (?). It > wasn't clear if there is a good solution for that. I've been in touch with the guys that proposed this for C23, and it seems that at least tcmalloc implements this. So I think that we need to do something sooner rather than later. As a stopgap, add redirs ofr the two new functions. Probably a full implementation after the April release. A+ Paul |
|
From: Feiyang C. <chr...@gm...> - 2023-02-28 01:18:40
|
On Tue, 28 Feb 2023 at 06:42, Paul Floyd <pj...@wa...> wrote: > > > > On 13-02-23 18:36, Mark Wielaard wrote: > > Hi valgrind developers, > > > >> Some issues we can discuss: > >> > >> - Pick a date for the April 3.21.0 release > >> Critical bugs that are must fix? > > > > We picked Friday April 14 for the RC and Friday April 28 for the final > > release. But we didn't designate any critical must fix bugs (yet?) > > Nothing critical, but always a lot of things that I'd like to get done > by then. > > > >> - loongarch - https://bugs.kde.org/show_bug.cgi?id=457504 > > > > This is split in several small patches and the contributor is really > > responsive. We should split the patches in those that change the core > > code and those that are are just for the loongarch backend. > > I had another look. There is a new signal, SISGSYS, and a lot of the > syscall changes are due to not handling SA_RESTART. I don't yet > understand why. > Hi, Paul, There are some 'assert' instructions on LoongArch that may trigger SIGSYS. The new architecture no longer defines SA_RESTORER on Linux. linux/include/uapi/asm-generic/signal-defs.h: /* * New architectures should not define the obsolete * SA_RESTORER 0x04000000 */ Thanks, Feiyang > >> - https://bugs.kde.org/show_bug.cgi?id=433859 aligned and sized stuff. > >> Do we have enough bits to track this efficiently? > > > > This is for C23, which isn't standard yet. So it won't need to go in > > soon. Julian said that he often disables the alloc/free/new/delete > > matching because it gets confused with some c++ allocators (?). It > > wasn't clear if there is a good solution for that. > > I've been in touch with the guys that proposed this for C23, and it > seems that at least tcmalloc implements this. So I think that we need to > do something sooner rather than later. As a stopgap, add redirs ofr the > two new functions. Probably a full implementation after the April release. > > > A+ > Paul > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Floyd, P. <pj...@wa...> - 2023-02-28 09:17:52
|
On 28/02/2023 02:18, Feiyang Chen wrote: > > Hi, Paul, > > There are some 'assert' instructions on LoongArch that may trigger SIGSYS. > The new architecture no longer defines SA_RESTORER on Linux. > > linux/include/uapi/asm-generic/signal-defs.h: > /* > * New architectures should not define the obsolete > * SA_RESTORER 0x04000000 > */ Hi Feiyang Thanks for the info. I was wondering if there was any link between the two, but it seems not. A+ Paul |