Blog: PITA bugs part 4

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Blog: PITA bugs part 4

Post by Z98 » Thu Jun 26, 2014 9:43 pm


hbelusca
Developer
Posts: 1128
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Blog: PITA bugs part 4

Post by hbelusca » Thu Jun 26, 2014 9:52 pm

Maybe the bump at 126 GeV, or more prosaically the deficit in the h→γγ channel at CMS (and the excess in the same channel in ATLAS) might be due to some FPGAs conspiring against data, just because of these kind of memory corruptions :D :D

Concerning the trigger rates, my numbers (for ATLAS), just to give an idea, are: data rate 40 MHz (each 25 ns, it's the bunches spacing). 23 peta-bytes of data per second generated by ATLAS. But interesting events (Higgs production for example) are rare: one event each 0.02 second.

Ah, and of course: http://www.infographicsshowcase.com/how ... fographic/ :P

justincase
Posts: 434
Joined: Sat Nov 15, 2008 4:13 pm

Re: Blog: PITA bugs part 4

Post by justincase » Thu Jun 26, 2014 10:57 pm

Since you brought up the Large Hadron Collider ...
I'm going to put some links here about one of the few rap songs I like. The LHC Rap (on YouTube or Vimeo) for more info about it see here and here.
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.

roytam
Posts: 61
Joined: Sat Dec 04, 2004 2:02 pm

Re: Blog: PITA bugs part 4

Post by roytam » Fri Jun 27, 2014 1:04 am

so how does time machine development goes?

PascalDragon
Posts: 123
Joined: Wed Aug 04, 2010 7:34 pm

Re: Blog: PITA bugs part 4

Post by PascalDragon » Fri Jun 27, 2014 7:29 am

I definitely agree with checking return codes. With that I fixed a few bugs in our own OS (mostly its userland; it's a microkernel architecture after all :P ) as well during the last few months. :D

Regards,
Sven
Free Pascal compiler developer

Oddjob64
Posts: 40
Joined: Sun Jun 01, 2014 10:21 am

Re: Blog: PITA bugs part 4

Post by Oddjob64 » Fri Jun 27, 2014 6:53 pm

That's pretty interesting. But since it isn't related to ReactOS, shouldn't it go in Off-Topic?

mrugiero
Posts: 482
Joined: Sun Feb 14, 2010 9:12 am

Re: Blog: PITA bugs part 4

Post by mrugiero » Fri Jun 27, 2014 7:31 pm

PascalDragon wrote:
I definitely agree with checking return codes. With that I fixed a few bugs in our own OS (mostly its userland; it's a microkernel architecture after all :P ) as well during the last few months. :D

Regards,
Sven
I don't understand why people doesn't check those. Even non-programmers should know that at least malloc should always be checked. I'm not a real programmer (only a hobbyist) and I know that.
On the subject, I found just yesterday some mallocs unchecked in a little physics sandbox.

hbelusca
Developer
Posts: 1128
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Blog: PITA bugs part 4

Post by hbelusca » Fri Jun 27, 2014 7:42 pm

About physicists and programming: maybe debugging ROOT might show interesting things xD (for those who do not know: http://root.cern.ch/drupal/ )

PascalDragon
Posts: 123
Joined: Wed Aug 04, 2010 7:34 pm

Re: Blog: PITA bugs part 4

Post by PascalDragon » Sat Jun 28, 2014 9:59 am

mrugiero wrote:I don't understand why people doesn't check those. Even non-programmers should know that at least malloc should always be checked. I'm not a real programmer (only a hobbyist) and I know that.
I think more often than not the opinion about such calls is "they normally work so I don't need to check them" or another good one is "I'll add error checking later, that's just for testing"... And then there are of course those changes you do quickly before a release and then you might forgot to pay of that technical debt... :roll:

Regards,
Sven
Free Pascal compiler developer

dfeuer
Posts: 1
Joined: Wed Jul 02, 2014 7:15 am

Re: Blog: PITA bugs part 4

Post by dfeuer » Wed Jul 02, 2014 7:34 am

PascalDragon wrote:
mrugiero wrote:I don't understand why people doesn't check those. Even non-programmers should know that at least malloc should always be checked. I'm not a real programmer (only a hobbyist) and I know that.
I think more often than not the opinion about such calls is "they normally work so I don't need to check them" or another good one is "I'll add error checking later, that's just for testing"... And then there are of course those changes you do quickly before a release and then you might forgot to pay of that technical debt... :roll:

Regards,
Sven
One possibility is that the programmers in question were spoiled by programming for Linux. Under Linux, malloc doesn't fail until it allocates a truly absurd amount of memory, and accidentally using too much memory leads to failures far from the allocation site, so there's not much point in even checking the return value of malloc under Linux.

mrugiero
Posts: 482
Joined: Sun Feb 14, 2010 9:12 am

Re: Blog: PITA bugs part 4

Post by mrugiero » Wed Jul 02, 2014 7:02 pm

dfeuer wrote: One possibility is that the programmers in question were spoiled by programming for Linux. Under Linux, malloc doesn't fail until it allocates a truly absurd amount of memory, and accidentally using too much memory leads to failures far from the allocation site, so there's not much point in even checking the return value of malloc under Linux.
I don't think that's the case of phisycists. I myself didn't know that Linux allocates lazily, and I program mostly for Linux (although I try to keep things portable). Also, the testing methodology is wrong, if Linux allocates lazily, as malloc won't fail if none of the previously allocated pages were used, which is not the common case. Most programs allocate and then use the memory, not that far off from allocation. So, in the real world, where one uses memory after allocating it, this calls will actually end up allocating the memory, most likely before you have to call malloc again. When you surpassed the limit for allocation, malloc will start returning NULL, as it will not have enough space for its control structures. And that's probably the logic kernel programmers followed when they decided not to check for memory availability before returning the valid pointer, although I disagree with such a practice. Deferring allocation to defer overhead is reasonable, deferring checking your bank account has the funds for the checks you emit, not so much.

hbelusca
Developer
Posts: 1128
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Blog: PITA bugs part 4

Post by hbelusca » Wed Jul 02, 2014 11:21 pm

mrugiero wrote:
dfeuer wrote: One possibility is that the programmers in question were spoiled by programming for Linux. Under Linux, malloc doesn't fail until it allocates a truly absurd amount of memory, and accidentally using too much memory leads to failures far from the allocation site, so there's not much point in even checking the return value of malloc under Linux.
I don't think that's the case of phisycists. I myself didn't know that Linux allocates lazily, and I program mostly for Linux (although I try to keep things portable). [...]
I myself didn't know about that, and, as a physicist too, I can assure you that they don't know that linux's malloc allocates lazily (unless maybe some people that only write physics codes, and even for them, I have doubts). We want to write things that do what we want, primarily, and those basic checks very often are not done (maybe because of an habit of writing also, e.g., C++ code where the operator new() throws an exception when a memory allocation fails??). So I'm not surprised by those kind of oversights. I even have an anecdote about those kinds of things (yet it was about obscure float <--> int conversion in some lattice QCD code).

NOTE: I don't try to apply this "philosophy" in ReactOS :P

mrugiero
Posts: 482
Joined: Sun Feb 14, 2010 9:12 am

Re: Blog: PITA bugs part 4

Post by mrugiero » Thu Jul 03, 2014 4:54 am

hbelusca wrote:and those basic checks very often are not done (maybe because of an habit of writing also, e.g., C++ code where the operator new() throws an exception when a memory allocation fails??).
That seems much more believable to be the case.
So I'm not surprised by those kind of oversights. I even have an anecdote about those kinds of things (yet it was about obscure float <--> int conversion in some lattice QCD code).
I'd like to hear about it.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests