assert fail on fRefCnt

[Patrick Fü]

Hey all, 

I'm using Skia in a project together with V8 JS engine. 

When ever I run the program in debug mode I get a lot of SkAsserts fails because of fRefCnt. It happens almost on every call to Skia and it looks like fRefCnt is not even initialised  right, because it has a high negative value every time. 

I tried to create a minimum program where it doesn't happen, but it even happens when calling :

 SkAutoTUnref<SkTypeface> skTypeface(SkTypeface::CreateFromFile(file));

Anyone any suggestion what the problem could be ? 

Thanks in advance. 

Patrick

[Mike Klein]

Hmm, that's a puzzler.

Do you have a stack trace from the crash?  Which assert fails?

It'd be helpful if you could also add `SkDebugf("in <function>, count is %d\n", fRefCnt);` to SkRefCntBase::SkRefCntBase(), SkRefCntBase::ref() and SkRefCntBase::unref() so we can watch the count move up and down.

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To post to this group, send email to skia-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/skia-discuss.
For more options, visit https://groups.google.com/d/optout.

[Hal Canary]

Or better yet:

    SkDebugf("in <function>, %p's count is %d\n", this, fRefCnt);

[Patrick Fü]

Hey Mike, 

thanks for the fast response.

I added the debug outputs and recognised that the output in ref and even the constructor are never printed. ( so never called ). 

With the example above. The stack trace and the console output look like the following. 

I had some similar issues with V8. After compiling V8 as a shared library these errors where gone. 

Console:

 in unref, 020A96B0's count is -842150451
..\libs\skia\include\core\skrefcnt.h:76: failed assertion "fRefCnt > 0"

Stack : 

> resonate_debug.exe!SkRefCntBase::unref()  Line 76 + 0x28 bytes C++
  resonate_debug.exe!SkSafeUnref<SkFontMgr>(SkFontMgr * obj)  Line 166 C++
  resonate_debug.exe!SkAutoTUnref<SkFontMgr>::~SkAutoTUnref<SkFontMgr>()  Line 183 + 0x17 bytes C++
  resonate_debug.exe!SkTypeface::CreateFromFile(const char * path, int index)  Line 148 + 0x22 bytes C++
  resonate_debug.exe!`dynamic initializer for 'skTypeface''()  Line 46 + 0x2a bytes C++
  msvcr120d.dll!52e3ebba()
  [Frames below may be incorrect and/or missing, no symbols loaded for msvcr120d.dll]
  resonate_debug.exe!__tmainCRTStartup()  Line 550 + 0xf bytes C
  resonate_debug.exe!mainCRTStartup()  Line 466 C
  kernel32.dll!76b17c04()
  ntdll.dll!7718b54f()
  ntdll.dll!7718b51a()
  resonate_debug.exe!SkCopyStreamToStorage(SkAutoMalloc * storage, SkStream * stream)  Line 863 + 0x8 bytes C++

Some more info: The samples in Skia, all work. Also everything runs within Openframeworks.   

Thanks.

Patrick

[Patrick Fü]

My bad I messed up compilation. Sure it calls ref and the constructor, but still when calling unref, the frefCnt is undefined. 

in SkRefCntBase, 002396B0's count is 1
in ref, 002396B0's count is 1
in unref, 002396B0's count is -842150451
..\libs\skia\include\core\skrefcnt.h:79: failed assertion "fRefCnt > 0"

[Patrick Fü]

Now I'm totally confused, I think it's not a problem of skia itself, but maybe you guys have an idea what the problem could be. 

When I debug through it step by step, VS shows me the right refcount, but still the assertion fails and the output is wrong. 

Am Montag, 30. März 2015 16:41:01 UTC+1 schrieb Patrick Fü:

[Mike Klein]

Are you running in a multithreaded setup?  Those assertions are known not to be thread-safe (though you should have to push it pretty hard to get them to break).

--

[Patrick Fü]

No I'm not. 

I just created a minimal console application with VisualStudio 2013 where I just load a typeface. It still fails. 

When working with release everything works fine. No memory leaks, nothing. 

[Patrick Fü]

I digged a bit deeper.

Also whenever I create a local SkPath variable on the stack it messes up my memory and I get a heap corruption  when I try to access other things afterwards.

I thought about that it could be possible that skia doesn't like to be linked static to my application. Do I need to consider some special settings when building skia as static library (/MDd) 

Thanks for the help. 

[Mike Klein]

Can you share some full compiling source that reproduces your problem?

[Patrick Fü]

Hey Mike, 

sure. Here is a test project running with VisualStudio2013. https://drive.google.com/file/d/0B7izWAhrwdjXd05HdUZKcE50a0E/view?usp=sharing

It also includes the compiled debug libs of skia.  

Thanks Patrick

[Vivek Kumar]

I also faced this issue which was solved when I disabled SK_INSTANCE_COUNTING in SkPostUserConfig.h

[Mark Kilgard]

I see this same problem.  What I debugged...

1) Compiling with Visual Studio 2013

1a)  Had VS 2013 SP4 but also upgraded to SP5 RC and still see the problem.

2)  I build the Skia libraries statically, so /MT (static) rather than default /MD (DLL) for the Runtime Library.  Everything in my app is consistently compiled with /MT.

3)  When the assertion fails, the (32-bit) address of fRefCnt is 4 bytes earlier.  Example: assertion reads fRefCnt from 0x0946B074 instead of proper 0x0946B078.

4)  The bogus value read is 0xcdcdcdcd, Visual Studio's uninitialized memory value.  That's the same -842150451 value Patrick reports.

5)  Happens in both Win32 and x64

It feels like there is something wrong about how the SkRefCntBase inheritance works, like there's two versions of fRefCnt, one that it is properly initialized and one that is not.  Maybe bad vtable accounting by Visual Studio?

I will try Vivek's proposal to disable SK_INSTANCE_COUNTING...

[Mark Kilgard]

It's actually SK_ENABLE_INST_COUNT (rather than SK_INSTANCE_COUNTING) but when I force this to zero always, Skia's reference counting with a static runtime works fine.

Eric, I recommend SK_ENABLE_INST_COUNT never be true for Windows builds (does it work on non-Windows builds?).  It doesn't seem to work; exactly why is unclear to me.

The normal way Skia's project files are build is for a DLL runtime, but I consider building Skia statically a valuable use case.

[Mike Klein]

I think we're pretty well converged on the opinion that SkInstCount is no longer useful tech, given things like Vagrind and leak sanitizer.  I'll take a shot at cleaning it up.

--

[Mike Klein]

Now gone at head.  Thanks for helping us identify this broken code guys!

[Vivek Kumar]

Hi Mike,

I encountered this problem while building for android and disabling SK_ENABLE_INST_COUNT did the trick for me.

Thanks

Vivek

[Mike Klein]

That's great.  If you sync up to head, that should no longer be necessary... we've removed the code SK_ENABLE_INST_COUNT was ENABLing.