Re: Bug#837606: general: system freeze

[Joël Krähemann]

Hi Abou Al Montacir

There some other tests you can run just comment appropriate ones out and
run again.
During Segmentation fault the program gets core dumped and won't continue.

If you have an older kernel it is possible that uninitialized condition
variables or mutices can
cause it. How ever, stack corruption could be that cause for that, too.

Bests,
Joël


On Thu, Sep 15, 2016 at 4:50 PM, Abou Al Montacir 
wrote:

> Hi Joël,
>
> On Wed, 2016-09-14 at 15:38 +0200, Joël Krähemann wrote:
>
> 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
>
> Thanks for that,
>
> Here are the results:
>
> $gcc -g -o mutex_fail_test mutex_fail_test.c `pkg-config --cflags --libs 
> cunit` -pthread
>
> $./mutex_fail_test
>
>
>  CUnit - A unit testing framework for C - Version 2.1-3
>  http://cunit.sourceforge.net/
>
>
> Suite: MutexFailTest
>   Test: test of pthread_mutex_lock concurrently with unassigned pointer 
> ...Segmentation fault
>
>
> --
>
> Cheers, Abou Al Montacir
>
>
>

Re: Bug#837606: general: system freeze

[Bart Schouten]

Lars Wirzenius schreef op 14-09-2016 12:15:


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.


Just hopping in to say that a UI freeze may very well be only a UI 
freeze, if you can still SSH into the box, you will know it is only your 
desktop environment (or X) that has frozen.


But sometimes this "freeze" will also render e.g. ctrl-alt-F1 
unoperable. So the only way, at that point, to test, is with a network 
user. If the freeze is actually in the UI, then most likely, the whole 
system would not have frozen.


Not sure at all if this is relevant.

Re: Bug#837606: general: system freeze

[Tollef Fog Heen]

]] The Wanderer 

> I suspect that, from his perspective, closing the bug report _makes_
> that report "disappear with no response" - or, at least, that it makes
> it do so to a greater extent than leaving it open with no answer would
> do.

Closing bugs don't make them disappear, we're not deleting them.

> "Bug report filed, remains open indefinitely with no response" comes
> across as "no one cares", true - but "bug report filed, closed without
> attempting to fix" comes across as rejection of the report, and
> therefore, of the idea that the report represents a valid problem. It's
> easy to see how the latter is a stronger negative than the former.

I'd be much more annoyed at not getting a response than «your bug report
lacks crucial detail needed to debug the problem».  The latter is
actionable on my part (I can try to find the information/answer the
questions).  In the former case, was there something wrong with the bug
report?  Did it even reach a human?  Did they just not care?  It's hard
to know, and it's completely inactionable (unactionable?) from the
submitter's point of view.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Bug#837606: general: system freeze

[The Wanderer]

On 2016-09-15 at 21:26, Wookey wrote:

> On 2016-09-15 18:04 -0700, Russ Allbery wrote:
> 
>> Debian is delightfully different.  We care about market share of 
>> *volunteers*, but we don't have to care (and indeed, I personally
>> don't care at all) about market share of *customers*.
> 
> Well put, but I reckon a lot of us would be happier if you (and
> Abou) used the term 'users', rather than 'customers'. I know I think
> that being a customer involves payment.

That was exactly my point: that although many people (including me!)
think that it does, other people do not - and, IMO, refusing or
otherwise failing to understand what they mean when they use the term
that way is not helpful.

There's a seed of a colorable argument otherwise in Russ's mail,
however, so I don't intend to push that terribly hard - especially not
given that the entire discussion would be at best arguably on-topic.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Bug#837606: general: system freeze

[Wookey]

On 2016-09-15 18:04 -0700, Russ Allbery wrote:

> Debian is delightfully different.  We care about market share of
> *volunteers*, but we don't have to care (and indeed, I personally don't
> care at all) about market share of *customers*.

Well put, but I reckon a lot of us would be happier if you (and Abou)
used the term 'users', rather than 'customers'. I know I think that
being a customer involves payment.

Anyway, to the point. Yes, please kill 'general' or at least its
reflection to debian-devel. It has seemed to me to be a tiresome
anacronism for a very long time. I have always assumed that it was
some very old BTS feature from when this was a much younger and
smaller project, that no-one could be bothered to tidy up.

I just ignore those mails now, after many years of noting that they
are largely useless bug reports barely worthy of the name, that
usually get promtly closed. Seems like a waste of everyone's time to
me.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Bug#837606: general: system freeze

[Russ Allbery]

The Wanderer  writes:
> On 2016-09-15 at 16:17, gregor herrmann wrote:

>> Debian can't lose customers because we have no customers because we're
>> not selling anything.

> This is a terminology difference.

It isn't for me.

For me, this is a very foundational and freeing concept.  Debian is not
participating in the giant obligation pressure game that you're referring
to.  Our users don't threaten us with withholding money.  We don't cajole
our customers into giving us money instead of someone else, or instead of
not spending it.  All of that rat race mechanic in which one is constantly
worrying about how one is perceived, whether other people will continue to
give one money, and whether one is losing "market share" does not apply in
the same sense to Debian.

Instead, we are a community of people building something *for ourselves*,
cooperatively.  If other people in the world want to use it, great!  If we
can help them use it, great!  Even better if we can attract them to
contribute.  And if they don't like it, great!  They can use something
else.  Or make it better.  They have free choice.  But they don't have
*control*.  They can't force us to make Debian something else because they
have lots of money, and we don't have to work on anything we don't want to
in order to keep customers.

> Others think of it in terms of the provision of any service, regardless
> of whether for compensation or not. For example, in my department at my
> workplace, the people in other parts of the organization to whom we
> provide computer support are called our (and our department's)
> "customers" - even though we don't charge them for the service.

But this is still the same type of thing, and it still doesn't apply to
Debian.  They're paying you to support them, although the money moves
indirectly and is subject to controls and rules set by other people.  But
you're not volunteers.  You are paid to serve the needs of customers.

Debian is a volunteer project.  We are not paid, nor bound, to serve the
needs of *anyone*.  We're doing this for ourselves, for each other.

There is so much fear and worry and careful public relations management in
the corporate world because everyone's jobs depend on the inflow of money
from people who have to be convinced to keep spending that money, and one
has to do all sorts of things one might not want to do, or agree with, in
exchange for maintaining those customers and that market share.

Debian is delightfully different.  We care about market share of
*volunteers*, but we don't have to care (and indeed, I personally don't
care at all) about market share of *customers*.  Someone choosing not to
use a commercial product threatens (in at least a small way) the continued
viability of that commercial product by withholding resources to pay all
the people working on it.  Someone choosing not to use Debian does not
threaten the viability of the Debian project.  We are a chosen community
who can continue building our distribution regardless of what the broader
world thinks of it.

This is a HUGE part of what the Debian project means to me.  It is far,
far more important than making any individual Debian user happy.  It's
what makes working on the project a fun and delightful hobby, as opposed
to a tedious, unpaid job.  So I get quite defensive about attempts to
introduce that sort of existential pressure and hostage-taking that comes
from serving "customers" or worrying about "market share."

> I think the key elements might be something like "we are offering
> something which we want them to accept, and they are relying on that
> offer".

But I *don't* want them to accept it.  That's the whole point.  I don't
care at all whether they accept it or not.  It's a gift, given freely to
the world, for anyone to take or leave as they choose.  And, most
importantly, it is in no way an ongoing *obligation* on me to make it fit
for their purpose.  If I take on that sort of obligation, I expect to be
paid in a conventional employee or contracting relationship, to compensate
for my loss of control over my priorities and the requirement to do a lot
of unenjoyable, tedious work to achieve things I don't care about at all.

When I do volunteer work in my free time, I am not bound by any of those
restrictions.  That's *why* I do it.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[The Wanderer]

On 2016-09-15 at 16:17, gregor herrmann wrote:

> On Thu, 15 Sep 2016 16:58:03 +0200, Abou Al Montacir wrote:

>> We don't care to loose customers because of an issue faced by
>> someone,
> 
> Debian can't lose customers because we have no customers because 
> we're not selling anything.

This is a terminology difference.

Some people think of "customers" only in context of buying and selling,
including the selling of services.

Others think of it in terms of the provision of any service, regardless
of whether for compensation or not. For example, in my department at my
workplace, the people in other parts of the organization to whom we
provide computer support are called our (and our department's)
"customers" - even though we don't charge them for the service.

I think the key elements might be something like "we are offering
something which we want them to accept, and they are relying on that
offer". That doesn't quite sum it up perfectly (it doesn't account or
the fact that, as I understand this broader sense of the word, one could
argue that e.g. a DD who uploads a package that needs validation through
the NEW queue is a customer of the ftpmasters), but it's as close as
I've managed to come thus far.

> As a consequence I still think that unspecific "bug reports" to 
> 'general' don't achieve more than frustrating both the reporter and 
> the subscribers of debian-devel, and that we should try to find 
> alternative ways for channeling such support requests.

Albeit (for reasons I can't seem to pin down into verbal form) somewhat
reluctantly, I have to agree with this.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Bug#837606: general: system freeze

[gregor herrmann]

On Thu, 15 Sep 2016 16:58:03 +0200, Abou Al Montacir wrote:

> In my case, when I get such a report for my package, I start instructing the
> user to gather more information. 

Right, me too.
But "general" is not a package but a catchall category where mails
get distributed to thousands of subscribers to debian-devel; and
with no information beyond "my system freezes" noone can feel
responsible for doing further bug triaging.

> We don't care to loose
> customers because of an issue faced by someone, 

Debian can't lose customers because we have no customers because
we're not selling anything.

And I'm not claiming that Debian is perfect -- far from it, and I'm
times and again frustrated over what I personally and what we as a
project could do more and better. But we all have to acknowledge the
limitations that we as a volunteer project face in practice -- Russ
has explained this aspect much better than I could.

As a consequence I still think that unspecific "bug reports" to
'general' don't achieve more than frustrating both the reporter and
the subscribers of debian-devel, and that we should try to find
alternative ways for channeling such support requests.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Billy Joel: In The Middle Of The Night


signature.asc
Description: Digital Signature

Re: Bug#837606: general: system freeze

[Russ Allbery]

The Wanderer  writes:

> I suspect that he feels that closing a bug report without having first
> tried to address it equals pretending that the problem reported in the
> bug report does not exist, and thus, represents an attempt to hide the
> fact that the problem does exist.

Okay.  Well, I think this is just obviously incorrect, so I suppose we're
at an impasse.  But thank you for the explanation!

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

Thanks The Wanderer,

You explained it better that I can ever do! It is a perception problem at the
first plane.
-- 
Cheers,
Abou Al Montacir

On Thu, 2016-09-15 at 13:39 -0400, The Wanderer wrote:
> On 2016-09-15 at 13:24, Russ Allbery wrote:
> 
> 
> 
> > > Abou Al Montacir  writes:
> 
> > 
> 
> >> Does improve distribution means hiding issues? I don't think it
> 
> >> is.
> 
> > 
> 
> > You keep using this term, but I have no idea what you mean by it.
> 
> > What information do you feel like we're hiding?
> 
> 
> 
> I suspect that he feels that closing a bug report without having first
> 
> tried to address it equals pretending that the problem reported in the
> 
> bug report does not exist, and thus, represents an attempt to hide the
> 
> fact that the problem does exist.
> 
> 
> 
> Given all the surrounding facts (some of which you've cited, quite
> 
> validly, in this thread), I'm not sure he's right, but - at least from
> 
> the outside, and as a general matter - the perception does seem to be a
> 
> reasonable one. Which only means that this represents a potential PR
> 
> problem, albeit perhaps a minor one.


signature.asc
Description: This is a digitally signed message part

Re: Bug#837606: general: system freeze

[The Wanderer]

On 2016-09-15 at 13:24, Russ Allbery wrote:

> Abou Al Montacir  writes:
> 
>> Does improve distribution means hiding issues? I don't think it
>> is.
> 
> You keep using this term, but I have no idea what you mean by it.
> What information do you feel like we're hiding?

I suspect that he feels that closing a bug report without having first
tried to address it equals pretending that the problem reported in the
bug report does not exist, and thus, represents an attempt to hide the
fact that the problem does exist.

Given all the surrounding facts (some of which you've cited, quite
validly, in this thread), I'm not sure he's right, but - at least from
the outside, and as a general matter - the perception does seem to be a
reasonable one. Which only means that this represents a potential PR
problem, albeit perhaps a minor one.

> Not listing that line item in a bug page basically no one looks at
> isn't "hiding information" in any meaningful sense that I can see.

In the perspective involved, it would be an attempt to hide the fact
that the problem was reported, and therefore that the problem apparently
existed.

> Basically, you're attributing to the Debian project considerably
> more resources, expertise, data management, bug classification, and
> analysis capabilities than we actually have, and then (apparently)
> getting angry and frustrated that we we're (from your perspective)
> somehow withholding those capabilities from this bug specifically.
> But that's not what's happening at all!  We have only a tiny fraction
> of the resources that you seem to think we have, and we're just
> trying to be explicit about what we can and can't do rather than
> having people's bug reports quietly disappear with no response.

I suspect that, from his perspective, closing the bug report _makes_
that report "disappear with no response" - or, at least, that it makes
it do so to a greater extent than leaving it open with no answer would
do.

"Bug report filed, remains open indefinitely with no response" comes
across as "no one cares", true - but "bug report filed, closed without
attempting to fix" comes across as rejection of the report, and
therefore, of the idea that the report represents a valid problem. It's
easy to see how the latter is a stronger negative than the former.
(Also, the former can more easily lead to "existing bug report
discovered, attempt is now made to fix it" or to "existing bug report
discovered, further information added which may be useful for a fix"
than can the latter.)


Which is probably to say that eliminating, or at the least reworking,
the 'general' package as a target for bug reports would probably be an
improvement if done properly. I'm not terribly fond of it as an idea at
first glance, but the logic behind it does seem fairly strong.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Bug#837606: general: system freeze

[Russ Allbery]

Abou Al Montacir  writes:

> Does improve distribution means hiding issues? I don't think it is.

You keep using this term, but I have no idea what you mean by it.  What
information do you feel like we're hiding?

Maybe you feel like closing a bug is always wrong unless the problem is
fully resolved?  That's a philosophy about bugs that, I'm afraid, is only
possible for small projects or projects with vast bug triage teams.  (If
you peruse the numerous articles on-line about backlog grooming, you'll
find that not closing unactionable bugs is widely considered a huge
*problem*, and experts in project management spend a lot of time telling
people to be much more aggressive about closing bugs than they want to
be.)

"My Debian system froze" is not useful information for anyone,
unfortunately, without a lot of additional work put into the problem.  You
say that you don't know how to do that work; I'm completely sympathetic,
since frequently I don't either.  However, not knowing doesn't change
anything about the situation, nor does it mean someone else is responsible
for helping you or I debug such problems.  That's just how volunteer
projects work.

Not listing that line item in a bug page basically no one looks at isn't
"hiding information" in any meaningful sense that I can see.

Basically, you're attributing to the Debian project considerably more
resources, expertise, data management, bug classification, and analysis
capabilities than we actually have, and then (apparently) getting angry
and frustrated that we we're (from your perspective) somehow withholding
those capabilities from this bug specifically.  But that's not what's
happening at all!  We have only a tiny fraction of the resources that you
seem to think we have, and we're just trying to be explicit about what we
can and can't do rather than having people's bug reports quietly disappear
with no response.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

On Wed, 2016-09-14 at 12:51 -0700, Russ Allbery wrote:
> > Abou Al Montacir  writes:
> 
> > 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.
> 
> However, this is unavoidable for that sort of bug report.  As much as
> anyone might like the situation to be different, Debian is not going to be
> able to act on a bug report with that little information complaining about
> a whole-system problem.  All that would happen if we didn't close the bug
> is that it would just be ignored forever, which I think is even worse.
There are little information because the guy reporting the bug, or the other one
suffering from it (me) does not know how to debug such a bug.

In my case, when I get such a report for my package, I start instructing the
user to gather more information. Later, if the user does not help I wait maybe
other users see the bug and help reproducing. If after several months none react
then I tag it and close it. If it happens someone reopen it I'm glad again to
hunt it.
> 
This is the reality of a volunteer project with limited time for triage of
bugs that haven't been traced technically to the faulty component.
Sometimes (rarely) someone will have the free time and desire to do that
tracing, but that can happen as easily (or more easily) on debian-user,
and isn't how we use the bug system.
bug system is meant to track issues, not to debug them. If an issue is there it
should appear, especially in an open source project. We don't care to loose
customers because of an issue faced by someone, but we are transparent enough to
tell users that someone discovered that and they may fall in it.
> 
Debian's bug system is a tool we use to improve the distribution, not a
user support channel.  We should not retain bugs that do not help us
achieve that.  It would be great if it could also be a user support
channel, but this is just unachievable for a volunteer-maintained
distribution like Debian, and we should avoid creating the impression that
we promise to do this.
Does improve distribution means hiding issues? I don't think it is.
-- 
Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

Hi Joël,

On Wed, 2016-09-14 at 15:38 +0200, Joël Krähemann wrote:
> 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
> 
> 
Thanks for that,

Here are the results:
$gcc -g -o mutex_fail_test mutex_fail_test.c `pkg-config --cflags --libs cunit`
-pthread
$./mutex_fail_test


 CUnit - A unit testing framework for C - Version 2.1-3
 http://cunit.sourceforge.net/


Suite: MutexFailTest
  Test: test of pthread_mutex_lock concurrently with unassigned pointer
...Segmentation fault

-- 
Cheers,
Abou Al Montacir



signature.asc
Description: This is a digitally signed message part

Re: Bug#837606: general: system freeze

[Vincent Lefevre]

On 2016-09-15 10:10:23 +0200, Abou Al Montacir wrote:
> That is very similar to the issue I'm experiencing. However I can
> reproduce this 100% when opening a page on linkedIn using epiphany
> browser.

Then I think that you should give strace information + system logs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

Hi Adam,
On Thu, 2016-09-15 at 04:07 +0200, Adam Borowski wrote:
> Even quite experienced people may have a hard time investigating a "system
> 
> freeze".
> 
> 
> 
> It just happens that I had two today; the system was working reliably before
> 
> with no unexplained crashes[1] at least in kernelly stuff.  Then out of a
> 
> sudden music gets stuck on a small buffer, screen freezes, no response
> 
> to anything, even no SysRq; ping worked for a short time then stopped. 
> 
> Half an hour later a repeat.  I've attached a serial console but it's
> 
> apparently a heisenbug -- no reproduces since.
That is very similar to the issue I'm experiencing. However I can reproduce this
100% when opening a page on linkedIn using epiphany browser.

I can send you the URL (privately), as I don't have serial port on my laptop.
But generally each time I try to accept someone's invitation or send an
invitation to someone, it happens. It works well with other browsers, but I do
prefer not changing my browser.
-- 
Cheers,
Abou Al Montacir



signature.asc
Description: This is a digitally signed message part

Re: Bug#837606: general: system freeze

[Adam Borowski]

On Wed, Sep 14, 2016 at 01:15:47PM +0300, Lars Wirzenius 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.

Even quite experienced people may have a hard time investigating a "system
freeze".

It just happens that I had two today; the system was working reliably before
with no unexplained crashes[1] at least in kernelly stuff.  Then out of a
sudden music gets stuck on a small buffer, screen freezes, no response
to anything, even no SysRq; ping worked for a short time then stopped. 
Half an hour later a repeat.  I've attached a serial console but it's
apparently a heisenbug -- no reproduces since.

But here's a little detail: two days ago I upgraded the kernel from 4.7.3 to
4.8-rc6 (good luck having an user mention that!).  I still don't know
anything more about a possible cause, though.

I'm not a super troubleshooter but at least I know where to stick a serial
console.  So, how would you proceed getting me to produce more information
for you?

When a system can't even write its logs, for a regular user that's it.  Even
if you managed to have the user try netconsole, it fails to work if there's
any bridging or VMs involved, on certain network cards, or if
(lspci;lsusb;...;pom)|md5sum - ends in a 0.  USB dies first in a crash, for
anything reliable you want serial on the sending side.  But, how often do
you find a serial port on new amd64, especially laptops?

> 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.

An user might call a freeze something that's a transient problem (like a
bout of swapping), or even a buggy full-screen program.  With that aside,
it's typically a kernel or X problem.

So let's assume the user, possibly with some help, did some investigation. 
But, how do you then know which package to make a report against?


Meow!



[1]. There _is_ an unsolved crasher in nouveau on my HW:
https://bugs.freedesktop.org/show_bug.cgi?id=79518
but at least it's isolated to a component that can be replaced (by nvidia
proprietary).
-- 
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week.  Protect your ARMs, folks!

Re: Bug#837606: general: system freeze

[Ben Hutchings]

On Wed, 2016-09-14 at 11:21 +0200, Abou Al Montacir wrote:
> Hi Holger,
> 
> On Tue, 2016-09-13 at 17:08 +, Holger Levsen wrote:
> > 
> > On Tue, Sep 13, 2016 at 04:15:54PM +0200, Abou Al Montacir wrote:
> > > 
> > > Control: reopen -1
> > > > 
> > > > > 
> > > > > Sorry, I don't think that the best way to solve this issue is
> > > > > to close the
> bug.
> > 
> > 
> > it seems you haven't realized two things:
> > - the "general" pseudo package is mostly useless
> Yes really? I don't agree here. It just pops issues that users can't
> affect, but
> there are real issues
> 
> > 
> > - when Ben closed this bug he gave a pointer to another bug which
>   basically is the same issue *and* a much better bug report. You
>   completly failed to reply to *that*.
> Yes that seems very close to the current problem, but is concerning a
> particular
> linux image that I'm not using.
[...]

I don't think it is specific to that particular version and
configuration.  The kernel's failure to charge DRM buffer allocations
to a task is a long-standing bug.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part

Re: Bug#837606: general: system freeze

[Russ Allbery]

Abou Al Montacir  writes:

> We are here facing a bug that appears only on some devices. The issue is
> tricky and the user does not have the skills to debug. The duty of the
> project is to help him investigating the right way so that the bug get
> solved.

No, it's not.

I hate to be this blunt about this, but I think you're laboring under some
serious confusions about what the Debian project is, and in fact this is
exactly why I don't like the general bug category.

The Debian project is absolutely not promising to, responsible for, or
even intending to help users debug problems with Debian.  Individual
contributors may *volunteer* to do this, but this is not something that we
promise in any way, and it's not something that users should expect.

This sounds harsh, but it's simply the reality of limited volunteer hours,
millions of users, and resource constraints.  We cannot provide this
service.  You'll find that nearly all commercial software companies with
full-time paid support staff *also* cannot provide this service because it
is *incredibly* time-intensive and expensive.

You *cannot* expect volunteers to do this type of "take all questions"
customer support for poorly-defined problems.  There are a very small
number of people who enjoy doing this and might volunteer to do it for
free, but the vast majority of people do not enjoy it and burn out on it
very quickly.  They are not going to do this work on their volunteer time.
If you want to promise to provide that, you *have* to pay people, usually
quite a lot of people, and usually a fair bit of money unless you want
minimally-trained people who are only following a script.

The Debian project will never provide this, and we should not give the
impression that we will.  It's simply not a goal of the project nor is it
something we have resources to do.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[Russ Allbery]

Abou Al Montacir  writes:

> 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.

However, this is unavoidable for that sort of bug report.  As much as
anyone might like the situation to be different, Debian is not going to be
able to act on a bug report with that little information complaining about
a whole-system problem.  All that would happen if we didn't close the bug
is that it would just be ignored forever, which I think is even worse.

This is the reality of a volunteer project with limited time for triage of
bugs that haven't been traced technically to the faulty component.
Sometimes (rarely) someone will have the free time and desire to do that
tracing, but that can happen as easily (or more easily) on debian-user,
and isn't how we use the bug system.

Debian's bug system is a tool we use to improve the distribution, not a
user support channel.  We should not retain bugs that do not help us
achieve that.  It would be great if it could also be a user support
channel, but this is just unachievable for a volunteer-maintained
distribution like Debian, and we should avoid creating the impression that
we promise to do this.

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[Marvin Renich]

[Please do not CC me, I am subscribed.  You seem to have a habit of
CC'ing the individuals to whose messages you are responding.  This is
contrary to this list's documented policy.]

* Abou Al Montacir  [160914 05:31]:
> The duty of the project is to
> help him investigating the right way so that the bug get solved. Not saying 
> ask
> the community.

No, the project has no such duty.  This is a volunteer project, and the
software is both free and without any warranty.  Your whole tirade on
this thread appears to take the attitude that not only are you paying
the project for the software, but you are also paying for support.

You have no _right_ to expect any response at all to a bug report.
Fortunately, the members of the Debian project _want_ to make it better,
so they do pay attention to reported bugs.  Note that the first response
to the bug submitter was a very detailed description of things he could
do to begin narrowing down the problem (this has been pointed out to you
before).

However, if a bug report does not give any information that allows a
maintainer to determine the cause of the bug, or even what piece of
software has the bug, it absolutely is appropriate for the maintainer to
ask the bug reporter to "ask the community" for help in narrowing down
the cause of the bug, even to the point of closing the original bug and
asking the reporter to submit a new, more specific, bug after further
investigation.

In this case, nothing in the bug report gives any indication whether the
problem is due to software or hardware.  A low-RAM/high-swap situation
can also give symptoms similar to these, and in that case the OS is
behaving as expected.

The Debian Bug Tracking System is not a user support forum.  On the page
describing how to report bugs[1], it says

  If you are unable to determine which package your bug report should be
  filed against, please send e-mail to the Debian user mailing list
  asking for advice.

If you want a bug fixed, treat the maintainers as if they are doing you
a personal favor, because they are!  They are under no obligation to you
whatsoever.

...Marvin

[1] https://www.debian.org/Bugs/Reporting

Re: Bug#837606: general: system freeze

[Jason Crain]

On 2016-09-14, Joël Krähemann  wrote:
> 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

There are hundereds of reasons for a system to freeze.  I don't know why
you think mutexes are behind the original reporter's problem.  Though if
you do find a problem, certainly do file a bug report, preferrably with
a good test case.

Re: Bug#837606: general: system freeze

[Joël Krähemann]

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

​

On Wed, Sep 14, 2016 at 12:15 PM, Lars Wirzenius  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
>

Re: Bug#837606: general: system freeze

[Lars Wirzenius]

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


signature.asc
Description: PGP signature

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

On Tue, 2016-09-13 at 15:51 -0700, Josh Triplett wrote:
> Russ Allbery wrote:
> > Should we just disable the general pseudo-package?  Is it serving a
> > sufficient useful purpose to warrant the constant (if somewhat slow)
> > stream of misdirected bug reports?
> 
> I don't think so, no.  Seems better for reportbug in the "I don't know
> where the bug is" case to just direct the user to debian-user, and
> perhaps provide some generally useful information for them to paste into
> the mail.
And the most probable answer will be we don't experience this bug, we can't
help!

We are here facing a bug that appears only on some devices. The issue is tricky
and the user does not have the skills to debug. The duty of the project is to
help him investigating the right way so that the bug get solved. Not saying ask
the community.

I would be in favor that general get forwarded to debian-user, but then it will
become a forum and many noise will raise. If developers will be lost there, then
what to say for lambda user?

I think warning that general bugs should be first discussed in debian-user is
the best option we can afford. But what ever is the option, the result is that a
bug does not get solved by just making reporting it more difficult.
-- 
Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

On Tue, 2016-09-13 at 14:27 -0700, Russ Allbery wrote:
> > Holger Levsen  writes:
> 
> > it seems you haven't realized two things:
> > - the "general" pseudo package is mostly useless
> > - when Ben closed this bug he gave a pointer to another bug which
> >   basically is the same issue *and* a much better bug report. You
> >   completly failed to reply to *that*.
> 
> > I'd close this bug again, but I gave up on caring about bugs in the
> > "general" pseudo package…
> 
> Should we just disable the general pseudo-package?  Is it serving a
> sufficient useful purpose to warrant the constant (if somewhat slow)
> stream of misdirected bug reports?
> 
> I feel like every bug report that's come into general would have been
> better as an email message to debian-user (assuming the reporter wasn't
> able to do a more detailed diagnosis and figure out which package was
> actually the cuase).
> 
> People always get frustrated when we close bugs to general as
> unactionable.  Maybe we're just creating an attractive nuisance and should
> shut it down entirely to avoid that frustration?
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.
-- 
Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part

Re: Bug#837606: general: system freeze

[Abou Al Montacir]

Hi Holger,

On Tue, 2016-09-13 at 17:08 +, Holger Levsen wrote:
> On Tue, Sep 13, 2016 at 04:15:54PM +0200, Abou Al Montacir wrote:
> > Control: reopen -1
> > > > Sorry, I don't think that the best way to solve this issue is to close 
> > > > the
bug.
> 
> it seems you haven't realized two things:
> - the "general" pseudo package is mostly useless
Yes really? I don't agree here. It just pops issues that users can't affect, but
there are real issues

> - when Ben closed this bug he gave a pointer to another bug which
  basically is the same issue *and* a much better bug report. You
  completly failed to reply to *that*.
Yes that seems very close to the current problem, but is concerning a particular
linux image that I'm not using.
Also here the freeze is almost immediate, I cant even type anything when it
happens.
> 
I'd close this bug again, but I gave up on caring about bugs in the "general"
pseudo package…
Do you think that closing this bug will help improving user experience? I don't.
I never close bugs on my packages because I think only few users are bothered.

 I do care about any user as I care about myself. This is for me the real 
meaning of "Debian is the universal operating system". Here universal means all 
kind of users.
-- 
Cheers,
Abou Al Montacir


signature.asc
Description: This is a digitally signed message part

Re: Bug#837606: general: system freeze

[Josh Triplett]

Russ Allbery wrote:
> Should we just disable the general pseudo-package?  Is it serving a
> sufficient useful purpose to warrant the constant (if somewhat slow)
> stream of misdirected bug reports?

I don't think so, no.  Seems better for reportbug in the "I don't know
where the bug is" case to just direct the user to debian-user, and
perhaps provide some generally useful information for them to paste into
the mail.

Re: Bug#837606: general: system freeze

[Holger Levsen]

On Tue, Sep 13, 2016 at 02:27:58PM -0700, Russ Allbery wrote:
> Should we just disable the general pseudo-package?  Is it serving a
> sufficient useful purpose to warrant the constant (if somewhat slow)
> stream of misdirected bug reports?

no, I think "general" is still useful, there are some valid bugs in it.

"base" OTOH and as previously discussed, can go.
 
> I feel like every bug report that's come into general would have been
> better as an email message to debian-user (assuming the reporter wasn't
> able to do a more detailed diagnosis and figure out which package was
> actually the cuase).

yeah, thats probably also true, but that doesnt change the fact that its
good to have some place for general bugs in Debian.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#837606: general: system freeze

[Russ Allbery]

Holger Levsen  writes:

> it seems you haven't realized two things:
> - the "general" pseudo package is mostly useless
> - when Ben closed this bug he gave a pointer to another bug which
>   basically is the same issue *and* a much better bug report. You
>   completly failed to reply to *that*.

> I'd close this bug again, but I gave up on caring about bugs in the
> "general" pseudo package…

Should we just disable the general pseudo-package?  Is it serving a
sufficient useful purpose to warrant the constant (if somewhat slow)
stream of misdirected bug reports?

I feel like every bug report that's come into general would have been
better as an email message to debian-user (assuming the reporter wasn't
able to do a more detailed diagnosis and figure out which package was
actually the cuase).

People always get frustrated when we close bugs to general as
unactionable.  Maybe we're just creating an attractive nuisance and should
shut it down entirely to avoid that frustration?

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#837606: general: system freeze

[Holger Levsen]

On Tue, Sep 13, 2016 at 04:15:54PM +0200, Abou Al Montacir wrote:
> Control: reopen -1
> Sorry, I don't think that the best way to solve this issue is to close the 
> bug.

it seems you haven't realized two things:
- the "general" pseudo package is mostly useless
- when Ben closed this bug he gave a pointer to another bug which
  basically is the same issue *and* a much better bug report. You
  completly failed to reply to *that*.

I'd close this bug again, but I gave up on caring about bugs in the "general"
pseudo package…


-- 
cheers,
Holger


signature.asc
Description: Digital signature