-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"this" corrupted #21
Comments
Looked at it for a few hours this morning; no solution yet. When R On Fri, Jun 6, 2014 at 4:45 AM, Tomas Sieger notifications@github.com
|
Thanks for sharing your theory.
At the same time, the bug seems to be (quite logically) related to global memory conditions (memory allocation, or possibly garbage collection?). When I inspect "this" using |
Thanks for looking into this more deeply. Yes, a new environment gets On Wed, Jun 11, 2014 at 12:28 PM, Tomas Sieger notifications@github.com
|
Thanks for the further investigation and explanation. The trick with the explicit calls to GC seems to work, however, I'm experiencing that the GC must be called much more often than on each 50th call to the handler, which makes my app terribly slow :-(. Also, the exact GC calling frequency is probably system-dependent and hard to guess in advance. In the meantime, I've tried to workaround the problem by bypassing the usage of the "bad" environments in the handler by running the handler in my own environment holding only the "event" parameter (and having the global env as the parent), and replacing "this" with a globally visible singleton (see below), but that still does not work, perhaps because the "bad" environments get still constructed and used during the call to the handler (even though the handler does not touch them).
BTW provided your theory is true (and pardon my limited knowledge) - would not be it possible to solve the problem by not sharing the object table between "this" and the environment enclosing the paintEvent handler, but copying the table (plus implementing some write-thru mechanism, if necessary)? |
Update: the issue demonstrates only in R3.1.0+ (not in previous R versions, even R 3.0.3). BTW I've noticed that NEWS to R 3.1.0 read: "Also, a number of other changes to reduce copying of objects; all contributed by or based on suggestions by Michael Lawrence." :-) |
This is an interesting finding, thanks. My changes were to the On Fri, Jun 13, 2014 at 7:46 AM, Tomas Sieger notifications@github.com
|
That's a good idea. Could you do it, please? |
Luke says that it is very unlikely to be an issue with the GC. He says that it must just be a slight change in memory allocation behavior. That may be the case; however, I've scoured the code for any missing PROTECT()s and came up empty. I just don't understand how the parent of the current frame of evaluation does not have a protected object table. |
I investigated it more deeply and found out the problem is that the object table gets finalized as the environment it is associated to is considered unreachable in finalization (even though the object table is in use at that time in another environment). I've injected R and qtbase with some debugs and mention some output here for reference:
The problem is that the handler environment a0x66765b0, which is associated with the object table a0x45977a8 (lines 09-14) seems to get lost somehow (?), i.e. not seen anymore (for the last time at line 17). As a finalizer has been associated with the object table a0x45977a8 thru the "lost" environment a0x66765b0 (line 12), and the environment can't be reached in CheckFinalizers() (just guessing, no direct evidence), the weak ref is set as "ready to be finalized" (line 18). Then, the object table gets reused in another environment a0x55de298 (lines 22-28) and used heavily (lines 29-42). However, even though the object table a0x45977a8 is in use, it is finalized (lines 49-50) along with its wrapping external pointer a0x66765e8. I do not know the reason why the environment a0x66765b0 disappears (or simply can't be reached). I'd happilly go deeper in it, but now I don't see where and how to look. I can also provide my hacked R/qtbase sources, if you like. As a quick, dirty (and incorrect!) workaround, I tried to instantiate a new object table on each request (see https://github.com/tsieger/qtbase/tree/object_table_copy), which seems Would it be possible to share the object table and enable proper finalization at the same time? Would you prefer to investigate the cause of the problem (i.e. in R, how?), or adapt qtbase? |
Thanks for this in-depth analysis. I really wish I understood the problem. If that is indeed the case, then it means that qtbase has made invalid On Sun, Jun 22, 2014 at 12:16 PM, Tomas Sieger notifications@github.com
|
qtbase resuses the table because it assumes R still references it, which is definitely not true in R 3.1.0, in which the table gets finalized for some unknown reason. It seems that my hack (https://github.com/tsieger/qtbase/tree/object_table_copy) is not incorrect - even though I create a new table on each request, all the tables act through the shared smoke object. This solution does not seem to leak, while the memory overhead is relatively small. |
Your fix should work and we very much appreciate your help. The main Please go ahead and submit a pull request. You might consider changing the On Fri, Jun 27, 2014 at 12:08 AM, Tomas Sieger notifications@github.com
|
Thank you. Hopefully, more light will be shed on this issue some day and this rather ad-hoc hack will become unnecessary. |
Pull requests have been merged. At this point, we should probably make a release of the 5.x branch to CRAN. Hopefully we get to the bottom of this some day. |
"this" gets corrupted in user's methods overriding Qt widgets methods (like the
paintEvent
method below) running the 'qt4' branch and Qt4:When resizing the window for a while (few seconds at most), or simply focusing and defocusing the window, R crashes saying:
The problem is neither related to creating several instances of the same class, nor to QtLabel.
Reproducible on Ubuntu 14.04 on Intel Core 2 Duo, both 64-bit and 32-bit, but also on Mac OS X 10.8.4, Mac Pro Pro 5.1, 6-Core Intel Xeon 2.4GHz, but not on Fedora Core Linux 3.6.11-1.fc17.i686.PAE i686.
Not sure whether the same problem appears using the main qtbase branch and Qt5.2+ (can't build qtbase for some reason - working on it).
Any ideas are welcome.
The text was updated successfully, but these errors were encountered: