https://bugs.kde.org/show_bug.cgi?id=430862
--- Comment #92 from Méven Car <meve...@gmail.com> --- (In reply to Flavio Cappelli from comment #88) > Hi Guys, > Hey Flavio, > Probably related. If you are not sure this sounds like a different bug, please open new bugs laser focused on your issue when you don't see duplicates with very close symptoms. Triagers and devs will mark them as duplicate if needed, but reporters can't do that and bugs reported as comments will very unlikely be fixed. See https://community.kde.org/Get_Involved/Issue_Reporting#Step_6:_File_a_high-quality_Bugzilla_ticket > I experiment continuous crashes in kdeinit5 opening simple text files with > kate. The crashes happen when (and only when) some particular pdf are in my > home directory (for example this one: https://arxiv.org/pdf/2010.08895). Do you mean in the Open/File dialog with previews enabled ? > Other pdf does not causes the crash. Also, Kwrite does not cause the crash, > and if I move the "critical pdf" under a subdir of my home, even kate does > not causes the crash anymore. > > I am on Manjaro stable, with latest updates (plasma 5.21.4, kde framework > 5.81.0, kde apps 21.04.0) A crash without backtrace is really hard/impossible to fix. Seems it could be this bug though. If you don't experience it with KDE Frameworks 5.82, it is not worth reporting/investigating anymore. > I experiment continuous crashes in kdeinit5 opening simple text files with > kate. The crashes happen when (and only when) some particular pdf are > in my > home directory (for example this one: https://arxiv.org/pdf/2010.08895). > Other pdf does not causes the crash. Also, Kwrite does not cause > the crash, and if I move the "critical pdf" under a subdir of my home, even > kate does not causes the crash anymore. Please report that (In reply to Duncan from comment #91) > (In reply to vindicator from comment #19) > > I'm curious why the other posts (specifically older) "has been marked as a > > duplicate of this bug" > > Bug is resolved/fixed (and my curiosity upon seeing it referenced in the git > logs is why I'm here) but I don't see that this question was ever answered. > So here's my (explicitly unofficial as I'm just another bugfiler, here and > elsewhere) attempt at an answer... > > There are (at least) two general bug-duplicate policies that can be employed > by devs choosing which bugs to mark as duplicates. Some products or bug > installations use one, some the other, and others may default to the first > but choose the second given a strong enough reason on an individual bug > basis. > > 1) Chronological order policy. Newer bugs are always duplicates of the > oldest, original bug. > > This could be argued to be the most "correct", but often has the practical > issue described/solved by the more pragmatic policy below. Still it's the > most reasonable default in the absence of a solid reason to override and is > thus favored where such priority-overrides are less common. In my > experience distros commonly have this policy, probably because of their > function as accumulators/packagers of software from various upstream sources. > > 2) Pragmatic "most useful information" policy. The "original" bug is > defined as the one with the most useful information already posted to it at > the time of the duplicate marking, regardless of which one was actually > filed first. > > In my experience this policy is more common on upstream original software > source providers, I'd suggest due to reasoning below, but extended to the > more general case (that is, not always will the most informative bug-filing > be the one with the commit-ID attached). > > Especially where (semi-)automated crash-report filing is used (as it is with > some kde components and apps, with the user's consent of course), the > often-automated chronologically first bugs may have very little additional > information, while a bug filed later, sometimes only because its author took > the time to collect and add additional information, has more practically > useful information in terms of actually fixing the bug. > > A recent bug I filed where earlier bugs were marked duplicates of mine is a > good example. For kde I run live-git versions built myself (using the > gentoo/kde project's build scripts so it's pretty automated) and I normally > update once or twice a week. I found a regression that wasn't there before > my last update, so I checked the git logs to see what changed and then > bisected the problem down to an individual commit. When I filed the bug it > had the git commit ID that triggered the problem in the subject line. There > was other information in the bug as well but honestly the commit ID was > probably the most helpful and the reason earlier bugs were marked dupes of > mine. > > But bisecting to an individual commit is a non-trivial amount of work and > takes time. By the time I did that there were other bugs reporting the > problem. But despite not being first, my bug was (presumably) considered to > have more useful info attached, as I said, likely the commit ID alone was > enough, so other bugs, including some filed earlier, were declared > duplicates of mine. Bug triaging is not a science and both triagers and reporters can make mistakes creating duplicates. Sometimes we peek earlier, sometimes best quality, sometimes just popularity or naming of the bug, there is no definitive rule, expect we want to limit the number of bugs, because a cacophony of bugs makes it harder to fix the bug, and harder for the bug reporters to see their bugs fixed. When we mark something as duplicate, triagers can copy over some data, and if he doesn't original reporters can copy or highlight it in the new main bug, I would encourage you to if you found value in it. You did some great job bisecting the origin of the bug, still the bug fix wasn't evident based on just that. Here the best stacktrace were sufficient to see approximately where the crash happened, and this was not sufficient to make the crash fix evident. With some effort, Fabian found it in the end. -- You are receiving this mail because: You are watching all bug changes.
