Re: [lldb-dev] Adding breakpad "symbol" file support
On 03/12/2018 23:54, Leonard Mosescu wrote: Yay! In case anyone is interested in the details, the Breakpad symbol format is documented here: https://chromium.googlesource.com/breakpad/breakpad/+/master/docs/symbol_files.md Thanks, Leonard, I actually didn't know about that document. :) (The format seemed straight-forward enough, so I wasn't really trying to find it either). I also forgot to add that these breakpad files might also be interesting as a test vehicle for the unwinder, as they provide a human-editable format for describing unwind instructions. pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] December LLVM bay-area social is this Thursday!
We'll be at Tied House as usual, starting on Thursday the 6th at 7pm! If you can, help us plan and RSVP here: https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyxqbjb/ See everyone there! ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [8.0.0 Release] Release schedule
On 03.12.2018 14:04, Hans Wennborg via lldb-dev wrote: > Hello everyone, > > I know 7.0.1 isn't out the door yet, and 8.0.0 isn't due for a while, > so relax :-) But I would like to get the schedule decided before folks > disappear over the holidays. > > According to the usual schedule, the branch would be created two weeks > into January, with the goal of shipping early March, so this is my > proposal: > > - 16 January 2019: Create the 8.0.0 branch, RC1 tagged soon after. > > - 6 February, RC2 tag. > > - 27 February, Final tag, release shipping a few days after. > > What do you think, especially release testers? > From NetBSD point of view Jan 16th is good. Earlier date would be nervous. > For the 6.0.0 release, the branch was created earlier in January after > a request from the community. This time I haven't heard anything, but > please let me know if a different schedule would be better for you. > > Ideally I'd like to finalize and post the schedule by the end of the week. > > Thanks, > Hans > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > signature.asc Description: OpenPGP digital signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] The lit test driver gets killed because of SIGHUP
Hi everyone, Since we switched to lit as the test driver we've been seeing it getting killed as the result of a SIGHUP signal. The problem doesn't reproduce on every machine and there seems to be a correlation between number of occurrences and thread count. Davide and Raphael spent some time narrowing down what particular test is causing this and it seems that TestChangeProcessGroup.py is always involved. However it never reproduces when running just this test. I was able to reproduce pretty consistently with the following filter: ./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ --filter="process" Bisecting the test itself didn't help much, the problem reproduces as soon as we attach to the inferior. At this point it is still not clear who is sending the SIGHUP and why it's reaching the lit test driver. Fred suggested that it might have something to do with process groups (which would be an interesting coincidence given the previously mentioned test) and he suggested having the test run in different process groups. Indeed, adding a call to os.setpgrp() in lit's executeCommand and having a different process group per test prevent us from seeing this. Regardless of this issue I think it's reasonable to have tests run in their process group, so if nobody objects I propose adding this to lit in llvm. Still, I'd like to understand where the signal is coming from and fix the root cause in addition to the symptom. Maybe someone here has an idea of what might be going on? Thanks, Jonas PS 1. There's two places where we send a SIGHUP ourself, with that code removed we still receive the signal, which suggests that it might be coming from Python or the OS. 2. If you're able to reproduce you'll see that adding an early return before the attach in TestChangeProcessGroup.py hides/prevents the problem. Moving the return down one line and it pops up again. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] The lit test driver gets killed because of SIGHUP
Have you tried an strace to see if it tells you who is sending the signal? On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hi everyone, > > Since we switched to lit as the test driver we've been seeing it getting > killed as the result of a SIGHUP signal. The problem doesn't reproduce on > every machine and there seems to be a correlation between number of > occurrences and thread count. > > Davide and Raphael spent some time narrowing down what particular test is > causing this and it seems that TestChangeProcessGroup.py is always > involved. However it never reproduces when running just this test. I was > able to reproduce pretty consistently with the following filter: > > ./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ --filter="process" > > Bisecting the test itself didn't help much, the problem reproduces as soon > as we attach to the inferior. > > At this point it is still not clear who is sending the SIGHUP and why it's > reaching the lit test driver. Fred suggested that it might have something > to do with process groups (which would be an interesting coincidence given > the previously mentioned test) and he suggested having the test run in > different process groups. Indeed, adding a call to os.setpgrp() in lit's > executeCommand and having a different process group per test prevent us > from seeing this. Regardless of this issue I think it's reasonable to have > tests run in their process group, so if nobody objects I propose adding > this to lit in llvm. > > Still, I'd like to understand where the signal is coming from and fix the > root cause in addition to the symptom. Maybe someone here has an idea of > what might be going on? > > Thanks, > Jonas > > PS > > 1. There's two places where we send a SIGHUP ourself, with that code > removed we still receive the signal, which suggests that it might be coming > from Python or the OS. > 2. If you're able to reproduce you'll see that adding an early return > before the attach in TestChangeProcessGroup.py hides/prevents the problem. > Moving the return down one line and it pops up again. > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] The lit test driver gets killed because of SIGHUP
On Tue, Dec 4, 2018 at 19:11 Zachary Turner via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Have you tried an strace to see if it tells you who is sending the signal? I used DTrace with the default kill.d script. It shows who sends what signal and there was nothing interesting other than debugserver sending signal 17 (SIGSTOP) to the inferior. This makes me think that the signal might be coming from the kernel? > On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi everyone, >> >> Since we switched to lit as the test driver we've been seeing it getting >> killed as the result of a SIGHUP signal. The problem doesn't reproduce on >> every machine and there seems to be a correlation between number of >> occurrences and thread count. >> >> Davide and Raphael spent some time narrowing down what particular test is >> causing this and it seems that TestChangeProcessGroup.py is always >> involved. However it never reproduces when running just this test. I was >> able to reproduce pretty consistently with the following filter: >> >> ./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ --filter="process" >> >> Bisecting the test itself didn't help much, the problem reproduces as >> soon as we attach to the inferior. >> >> At this point it is still not clear who is sending the SIGHUP and why >> it's reaching the lit test driver. Fred suggested that it might have >> something to do with process groups (which would be an interesting >> coincidence given the previously mentioned test) and he suggested having >> the test run in different process groups. Indeed, adding a call to >> os.setpgrp() in lit's executeCommand and having a different process group >> per test prevent us from seeing this. Regardless of this issue I think it's >> reasonable to have tests run in their process group, so if nobody objects I >> propose adding this to lit in llvm. >> >> Still, I'd like to understand where the signal is coming from and fix the >> root cause in addition to the symptom. Maybe someone here has an idea of >> what might be going on? >> >> Thanks, >> Jonas >> >> PS >> >> 1. There's two places where we send a SIGHUP ourself, with that code >> removed we still receive the signal, which suggests that it might be coming >> from Python or the OS. >> 2. If you're able to reproduce you'll see that adding an early return >> before the attach in TestChangeProcessGroup.py hides/prevents the problem. >> Moving the return down one line and it pops up again. >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > -- Sent from my iPhone ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] The lit test driver gets killed because of SIGHUP
Do you know if it’s Darwin specific? If so, maybe someone internally can offer guidance on how to diagnose (like on the kernel team)? When you aren’t using the lit driver, does the signal still get delivered (and we just handle it better), or does it not get delivered at all? On Tue, Dec 4, 2018 at 9:12 PM Jonas Devlieghere wrote: > > > On Tue, Dec 4, 2018 at 19:11 Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Have you tried an strace to see if it tells you who is sending the signal? > > > I used DTrace with the default kill.d script. It shows who sends what > signal and there was nothing interesting other than debugserver sending > signal 17 (SIGSTOP) to the inferior. This makes me think that the signal > might be coming from the kernel? > > >> On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Hi everyone, >>> >>> Since we switched to lit as the test driver we've been seeing it getting >>> killed as the result of a SIGHUP signal. The problem doesn't reproduce on >>> every machine and there seems to be a correlation between number of >>> occurrences and thread count. >>> >>> Davide and Raphael spent some time narrowing down what particular test >>> is causing this and it seems that TestChangeProcessGroup.py is always >>> involved. However it never reproduces when running just this test. I was >>> able to reproduce pretty consistently with the following filter: >>> >>> ./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ --filter="process" >>> >>> Bisecting the test itself didn't help much, the problem reproduces as >>> soon as we attach to the inferior. >>> >>> At this point it is still not clear who is sending the SIGHUP and why >>> it's reaching the lit test driver. Fred suggested that it might have >>> something to do with process groups (which would be an interesting >>> coincidence given the previously mentioned test) and he suggested having >>> the test run in different process groups. Indeed, adding a call to >>> os.setpgrp() in lit's executeCommand and having a different process group >>> per test prevent us from seeing this. Regardless of this issue I think it's >>> reasonable to have tests run in their process group, so if nobody objects I >>> propose adding this to lit in llvm. >>> >>> Still, I'd like to understand where the signal is coming from and fix >>> the root cause in addition to the symptom. Maybe someone here has an idea >>> of what might be going on? >>> >>> Thanks, >>> Jonas >>> >>> PS >>> >>> 1. There's two places where we send a SIGHUP ourself, with that code >>> removed we still receive the signal, which suggests that it might be coming >>> from Python or the OS. >>> 2. If you're able to reproduce you'll see that adding an early return >>> before the attach in TestChangeProcessGroup.py hides/prevents the problem. >>> Moving the return down one line and it pops up again. >>> ___ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > -- > Sent from my iPhone > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] The lit test driver gets killed because of SIGHUP
On Tue, Dec 4, 2018 at 22:03 Zachary Turner wrote: > Do you know if it’s Darwin specific? If so, maybe someone internally can > offer guidance on how to diagnose (like on the kernel team)? > Finding that out is part of the reason I sent this mail. We’ve only seen it on Mac Pros and iMac Pros. I haven’t tried on Linux yet. If someone with a specced machine would have a go at the the command I sent earlier that would be really appreciated. I can try myself in a VM tomorrow, but if it doesn’t reproduce it’ll be bad to tell whether it was because of the VM or not. When you aren’t using the lit driver, does the signal still get delivered > (and we just handle it better), or does it not get delivered at all? I wasn’t able to reproduce with dotest.py or the lldb-dotest wrapper. I installed a signal handler for SIGHUP and it never triggered. Since the signal doesn’t show up in my DTrace output I can’t be sure if it actually reproduces, but the handler doesn’t execute. It also doesn’t fire in the lit case, which adds to my confusion. > On Tue, Dec 4, 2018 at 9:12 PM Jonas Devlieghere > wrote: > >> >> >> On Tue, Dec 4, 2018 at 19:11 Zachary Turner via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Have you tried an strace to see if it tells you who is sending the >>> signal? >> >> >> I used DTrace with the default kill.d script. It shows who sends what >> signal and there was nothing interesting other than debugserver sending >> signal 17 (SIGSTOP) to the inferior. This makes me think that the signal >> might be coming from the kernel? >> >> >>> On Tue, Dec 4, 2018 at 6:49 PM Jonas Devlieghere via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: >>> Hi everyone, Since we switched to lit as the test driver we've been seeing it getting killed as the result of a SIGHUP signal. The problem doesn't reproduce on every machine and there seems to be a correlation between number of occurrences and thread count. Davide and Raphael spent some time narrowing down what particular test is causing this and it seems that TestChangeProcessGroup.py is always involved. However it never reproduces when running just this test. I was able to reproduce pretty consistently with the following filter: ./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ --filter="process" Bisecting the test itself didn't help much, the problem reproduces as soon as we attach to the inferior. At this point it is still not clear who is sending the SIGHUP and why it's reaching the lit test driver. Fred suggested that it might have something to do with process groups (which would be an interesting coincidence given the previously mentioned test) and he suggested having the test run in different process groups. Indeed, adding a call to os.setpgrp() in lit's executeCommand and having a different process group per test prevent us from seeing this. Regardless of this issue I think it's reasonable to have tests run in their process group, so if nobody objects I propose adding this to lit in llvm. Still, I'd like to understand where the signal is coming from and fix the root cause in addition to the symptom. Maybe someone here has an idea of what might be going on? Thanks, Jonas PS 1. There's two places where we send a SIGHUP ourself, with that code removed we still receive the signal, which suggests that it might be coming from Python or the OS. 2. If you're able to reproduce you'll see that adding an early return before the attach in TestChangeProcessGroup.py hides/prevents the problem. Moving the return down one line and it pops up again. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> ___ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >> -- >> Sent from my iPhone >> > -- Sent from my iPhone ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
