On Thursday, 11 December 2014 at 18:36:59 UTC, Steven
Schveighoffer wrote:
My analysis so far:
2. In the array append code, the block attributes are obtained
via GC.query, which has this code for getting the attributes:
On Friday, 12 December 2014 at 12:53:00 UTC, Ruslan Mullakhmetov
wrote:
On Thursday, 11 December 2014 at 18:36:59 UTC, Steven
Schveighoffer wrote:
My analysis so far:
4. If your code is multi-threaded, but using __gshared, it can
make the cache incorrect. Are you doing this?
the app is
On Friday, 12 December 2014 at 15:50:26 UTC, Steven Schveighoffer
wrote:
Can I email you at this address? If not, email me at the
address from my post to let me know your contact, no reason to
work through building issues on the public forum :)
-Steve
reach me at theambient [] me__com
On Wednesday, 10 December 2014 at 02:43:19 UTC, ketmar via
Digitalmars-d-learn wrote:
On Tue, 09 Dec 2014 17:18:44 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
but i still have no clue how to overcome GC =(
why do you want to fight with GC? most
On Tuesday, 9 December 2014 at 21:38:57 UTC, Steven Schveighoffer
wrote:
On 12/9/14 2:56 PM, Steven Schveighoffer wrote:
On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote:
array holds 11 64bit pointers but it's block size is only 128
bytes 11
* 64 = 704 bytes. what's wrong with this
On Wednesday, 10 December 2014 at 08:46:12 UTC, Ruslan
Mullakhmetov wrote:
yes. that was the mistake. also after fixing bug in Blk
Attributes printing i got more reasonable attrs
for object blk: FINALIZE
for array of objects blk: NO_SCAN APPENDABLE
this is sound good except for NO_SCAN.
...
On Wednesday, 10 December 2014 at 12:52:24 UTC, Ruslan
Mullakhmetov wrote:
why and how this happens? can anybody explain it to me?
I tried to extract this and saw NO NO_SCAN attrs after moving blk:
the following piece of output produced by
http://dpaste.dzfl.pl/6f773e17de92
len: 6
On Wednesday, 10 December 2014 at 13:00:45 UTC, ketmar via
Digitalmars-d-learn wrote:
can you give us a minified code that causes this behavior?
see previous post. the problem vanish if i try to extract it.
Hi,
I experience very strange problem: GC somehow collects live
objects.
I found it because i got segfaults. After debugging and tracing i
found this is because of accessing not allocated memory.
I did the following checks:
- added to some class invariant check for access to suspicious
On Tuesday, 9 December 2014 at 14:23:06 UTC, Steven Schveighoffer
wrote:
On 12/9/14 8:54 AM, Ruslan Mullakhmetov wrote:
Hi,
I experience very strange problem: GC somehow collects live
objects.
I found it because i got segfaults. After debugging and
tracing i found
this is because of
On Tuesday, 9 December 2014 at 16:53:02 UTC, Steven Schveighoffer
wrote:
On 12/9/14 11:17 AM, ketmar via Digitalmars-d-learn wrote:
On Tue, 09 Dec 2014 14:52:53 +
Ruslan Mullakhmetov via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Tuesday, 9 December 2014 at 14:23:06
On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote:
It may happen if only reference to an object is stored in
memory block marked as data-only (using ubyte[] for a buffer is
probably most common reason I have encountered)
Thanks for interesting hypothesis, but that's not the issue.
On Tuesday, 9 December 2014 at 19:56:30 UTC, Steven Schveighoffer
wrote:
On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote:
On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote:
i checked attributes for GC block holding this array:
FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR
That does
13 matches
Mail list logo
