Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
watchdog.module
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
10 Oct 2008 at 05:28 UTC
Updated:
8 Dec 2008 at 06:21 UTC
Jump to comment: Most recent file
Comments
Comment #1
dave reidAre you getting an error for this? I don't see why this needs to be changed.
Comment #2
kbahey commentedI am not sure what this patch is trying to solve.
Can you explain what error do you get or wrong behavior that led you to do it this way?
Comment #3
AlexisWilke commentedCode correctness.
The following is what you have now. Simplified. If you cannot see the BIG error, then I cannot help. That sample will run. I'm not too sure when it will stop however. The string "I'm running the loop!", according to the comment in the real function, will be written once. Will it?
Code correctness in the entire system is what makes the system work better. And the idea of not fixing something because no one has a problem with it, even though it is wrong, does not make sense, does it?
Thank you
Alexis Wilke
Comment #4
dave reidBut this is not necessarily a recursive function. What happens in the watchdog invokes hook_watchdog in other modules. If those modules cause an error, it will cause another call to watchdog for the new error. In that case, the $avoid_recursivity is TRUE, so the second watchdog call does not execute and stops recursion.
Comment #5
kbahey commentedI see what you are seeing from a theoretical point of view, when programming threads and such.
If a second request comes in to watchdog while the first one is active, then regardless of your patch, we have the same result, we do not execute anything between the braces.
There is no loop in watchdog, and the end result is the same : turn the semaphore off after the critical code executes.
So, at best it is a code style issue, but not a practical issue that needs to be solved.
Comment #6
dave reidA more accurate simulation is this:
which if run, will result in:
and no recursion, exactly as the original code intended.
Comment #7
AlexisWilke commentedDave,
I'm sorry you cannot see it.
I'll try again...
Your example does prevent the loop only on the 1st error, not the following ones. Why can't you see it?!
And this time the result is something a bit more complex...
Let me know if you find a different result.
And of course, feel free to move the line were we put the variable back to FALSE inside the if() to see the difference. Now this may already have caused mayhem to a few people...
kbahey, I do not know what programming theory you are talking about, but you may want to test the code properly: TWICE instead of ONCE. And my sample has no threading issue. Actually, that code, even fixed, would NOT work in a multi-threaded environment. For that you'd need a lock. But that's fine, PHP is not multi-threaded anyway.
Comment #8
dave reidAha! I see what you mean now! Sorry if this got a little heated, but just wanted to understand the problem completely.
This is a valid bug in Drupal 7 CVS. There is no recursion variable checks in D6 or 5. Maybe there should be (should be separate issue)? Anyway, bumping version to 7.x-dev and attaching patch for review.
Comment #9
dave reidForgot version bump.
Comment #10
AlexisWilke commentedHa! Yes... not even in D6... 8-)
I'm glad you understand in the end.
Thank you.
Alexis
Comment #11
kbahey commentedAlexis
Now it is clear. If the code sample was complete from the start, we would have seen it earlier.
Thank you for your persistence and patience.
The patch does apply, but I have not tested it.
Setting this to normal priority.
Comment #12
dave reidBumping back to code needs review.
Comment #14
AlexisWilke commentedHi Khalid,
I noticed that this was still open and now the computer tells me that the patch is not passing some tests.
Am I supposed to do something about it?!
Thank you.
Alexis
Comment #15
damien tournoud commented@AlexisWilke: it was your responsibility, as a patch submitter, to clearly explain what issue you intended to solve with your original patch. "I think this is wrong" is clearly not a good enough explanation. Patch reviewers are not (always) clairvoyant, so the more details you give, the better.
Latest patch still apply, but our test bot is having some issues at the moment. I rerolled the patch in #8, with additional comments. The original code was introduced in (you will not believe it), the huge, kitten-killer, monstrous and un-reviewable DB: the new generation patch. I believe that the non-recursion logic of this should be back-ported to D6, once D7 has been fixed.
Comment #16
AlexisWilke commentedHey!
That's it 8-) A 344Kb patch... 8-) (that DB the new generation node)
You see, the author accepted and it is one line that was at the wrong place, he even ran a test to see the problem and it does not get fixed and back ported immediately. It would take under 1h altogether and one less bug in the whole system. Then you avoid the 344Kb patches that fixes all these bugs at once... Okay, j/k, I just won't have the time to read 302 messages. But I can see that the problem is quite different. I just think that the process is very slow for such simple patches to be applied.
Thank you for posting a new patch and letting me know that the system has a problem because all my patches are generated failures now... This was not the only one!
Best,
Alexis
Comment #17
dries commentedCommitted to CVS HEAD. Thanks for the careful analysis and review, folks! Thanks Alexis.