[Interest] Segmentation fault on exiting Qt event loop

Jason H jhihn at gmx.com
Wed Jan 2 16:42:29 CET 2019


> Sent: Wednesday, January 02, 2019 at 7:24 AM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: interest at qt-project.org
> Subject: Re: [Interest] Segmentation fault on exiting Qt event loop
>
> On Tuesday, 1 January 2019 14:48:59 -02 Ramakanth Kesireddy wrote:
> > Please find the sample application attached which throws segmentation fault
> > on click of Quit button in the UI.
> 
> I asked for a short example (200 lines or less, single file). You sent a 9-
> file source plus a .ui file.
> 
> I also asked for something that compiles and reproduces the error with a 
> current version of Qt 5. Your code doesn't. Even after fixing it to compile 
> with Qt 5, it produces no error with 5.12, either because you've removed the 
> problem from your test, or because the problem you're running into does not 
> exist in my version.

I often find that when generating a minimal example, I find the true nature of the bug. Sometimes, it's my fault, other times it's really a bug. While no one wants to actually do the exercise of creating the minimal test case (because it should "just work"), It's invaluable because you explicitly state what you did to get the behavior your got. Really, a minimal example is not an unreasonable ask, it is the minimal ask that can be done with any sufficient specificity. Then, if a fix to Qt is actually needed, your example can become one or more test cases. It's not reasonable to ask someone else to figure out your problem and then come to a solution for it. Also, when supplying the example, you can also show when it does work. (Although this technically goes beyond minimal, which is fine). This proves that you understand the API and hints to the defective mechanism in the code.

In my recent years, having been influenced by having been at various Agile departments, I am finding the approach of first principles ( https://en.wikipedia.org/wiki/First_principle ) applies well to Agile. I can't really express how this affects my work, other than to say to prove it can be done in general then done with specificity to your use case. If you target your use case directly and first, then you don't know if 1) your premise is correct, 2) or that you're going about it correctly (including API usage) or 3) your use case is correct. Once the problem is solved for the general case, you can solve for any specific cas. Knowing that 1 and 2 work really help focus your efforts. This also helps identify reusable and conceptual APIs that should be created. Solve the equation, *then* plug your values in. Then when developing larger systems, you know all the components work, and it's just a matter of tying them together. 







More information about the Interest mailing list