Hi reproducing the critical parts in a unit test would be helpful
Something like in the attachment. install dependencies: apt-get install libcunit1-dev Compile with gcc -g -o mutex_fail_test mutex_fail_test.c `pkg-config --cflags --libs cunit` -pthread launch ./mutex_fail_test Bests, Joël mutex_fail_test.c <https://drive.google.com/file/d/0B7HNM59xk38wRHpGLUdBci1ZT3c/view?usp=drive_web> On Wed, Sep 14, 2016 at 12:15 PM, Lars Wirzenius <l...@liw.fi> wrote: > On Wed, Sep 14, 2016 at 11:23:56AM +0200, Abou Al Montacir wrote: > > Because you think people will not be frustrated if they experience a bug > and > > that we prevent them to raise bugs? Hiding reality is always bad?. Look > at the > > original reporter last message. He seems quite disappointed by the > project > > reaction. He should feel as we don't care about our users. I personally > > sometimes feel the same. > > We do care about our users. However, due to the realities of volunteer > projects, we need users to help us help them. Reporting a bug that > "system freezes" isn't a problem that has an obvious solution: even > assuming that we understand what "system freezes" actually means, > there's not nearly enough informatino to figure out what causes it. > > I note that the first mail from someone else than the reporter in the > bug report that started this thread asks for a whole lot more > information. Right after that, someone else closed the bug report, > saying it's not a useful bug report. And I'm afraid I agree. As > reported, it's not a useful bug report, and there's no hint of where > to even start looking for the fault. > > The thing is, a desktop system is a very complicated system. There's > thousands of programs interacting, plus a lot of hardware, and a > "general freeze" may be caused by pretty much any of them. > > This is why bugs reported against the psudo-package general are mostly > useless: there's rarely enough information to do anything about them > except start a long interrogation process to gather the information. > That process tends to happen more efficiently via other channels, > including the debian-user lists, IRC, and in-person meetings. Once > enough information has been gathered, it may turn out to be an actual > bug that can be reported against the most likely culprit. Or it might > turn out to be a hardware problem, which we can't fix, or a user > mistake. > > So I agree that we could get rid of the "general" pseudo-package, if > only to push the fact-finding phase to a more efficient channel. > > Also, to be quite blunt, when I'm doing user support for hobby > projects (of which Debian is one), I get de-motivated really easily > when bugs are reported in a hostile fashion. See the second mail in > the bug report that started this thread. Once I have no motivation, I > stop participating in helping that person. I'm not asking for > kowtowing and I ask that my 'leetness to be given respect, but I do > require to not be treated badly. > > Work with me, and I'll work with you. > > -- > I want to build worthwhile things that might last. --joeyh >
