Browser SubProcess Exception Code: e0000008

[mgteg]

When executing some javascript on a Google Map, the Browser SubProcess exits with Exception Code e0000008.

Here are the libraries I am using:
CefSharp v57 (https://github.com/cefsharp/CefSharp)
CEF 3.2987.1601 (Windows 32-bit)

Here is the stack trace:

Code: Select all

   KERNELBASE.dll!_RaiseException@16()   Unknown
    libcef.dll!SkDiscardableMemory::Create(unsigned int bytes) Line 40   C++
    libcef.dll!SkResourceCacheDiscardableAllocator::allocPixelRef(SkBitmap * bitmap, SkColorTable * ctable) Line 195   C++
    libcef.dll!SkBitmap::allocPixels(SkBitmap::Allocator * allocator, SkColorTable *) Line 402   C++
    libcef.dll!SkBitmapScaler::Resize(SkBitmap * resultPtr, const SkPixmap & source, SkBitmapScaler::ResizeMethod destWidth, int destHeight, int allocator, SkBitmap::Allocator *) Line 247   C++
    libcef.dll!SkDefaultBitmapControllerState::processHQRequest(const SkBitmapProvider & provider) Line 156   C++
    libcef.dll!SkDefaultBitmapControllerState::SkDefaultBitmapControllerState(const SkBitmapProvider & provider, const SkMatrix & inv, SkFilterQuality qual, bool canShadeHQ) Line 247   C++
    libcef.dll!SkDefaultBitmapController::onRequestBitmap(const SkBitmapProvider & bm, const SkMatrix & inverse, SkFilterQuality quality, void * storage, unsigned int size) Line 268   C++
    libcef.dll!SkBitmapProcInfo::init(const SkMatrix & inv, const SkPaint & paint) Line 113   C++
    libcef.dll!SkBitmapProcLegacyShader::MakeContext(const SkShader & shader, SkShader::TileMode tmx, SkShader::TileMode tmy, const SkBitmapProvider & provider, const SkShader::ContextRec & rec, void * storage) Line 229   C++
    libcef.dll!SkImageShader::onCreateContext(const SkShader::ContextRec & rec, void * storage) Line 56   C++
    libcef.dll!SkSmallAllocator<3,3332>::createWithIniter<<lambda_f7b7a3c26740bb3f83cf2ae8e8421719> >(unsigned int size, SkBlitter::Choose::__l42::<lambda_f7b7a3c26740bb3f83cf2ae8e8421719> initer) Line 76   C++
    libcef.dll!SkBlitter::Choose(const SkPixmap & device, const SkMatrix & matrix, const SkPaint & origPaint, SkSmallAllocator<3,3332> * allocator, bool drawCoverage) Line 905   C++
    libcef.dll!SkAutoBlitterChoose::SkAutoBlitterChoose(const SkPixmap & dst, const SkMatrix & matrix, const SkPaint & paint, bool) Line 56   C++
    libcef.dll!SkDraw::drawRect(const SkRect & prePaintRect, const SkPaint & paint, const SkMatrix * paintMatrix, const SkRect * postPaintRect) Line 868   C++
    libcef.dll!SkDraw::drawBitmap(const SkBitmap & bitmap, const SkMatrix & prematrix, const SkRect * dstBounds, const SkPaint & origPaint) Line 1355   C++
    libcef.dll!SkBitmapDevice::drawBitmapRect(const SkDraw & draw, const SkBitmap & bitmap, const SkRect * src, const SkRect & dst, const SkPaint & paint, SkCanvas::SrcRectConstraint constraint) Line 353   C++
    libcef.dll!SkCanvas::internalDrawBitmapRect(const SkBitmap & bitmap, const SkRect * src, const SkRect & dst, const SkPaint * paint, SkCanvas::SrcRectConstraint constraint) Line 2489   C++
    libcef.dll!SkCanvas::onDrawBitmapRect(const SkBitmap & bitmap, const SkRect * src, const SkRect & dst, const SkPaint * paint, SkCanvas::SrcRectConstraint constraint) Line 2500   C++
    libcef.dll!SkCanvas::drawBitmapRect(const SkBitmap & bitmap, const SkRect & dst, const SkPaint * paint, SkCanvas::SrcRectConstraint constraint) Line 1987   C++
    libcef.dll!SkPixmap::scalePixels(const SkPixmap & dst, SkFilterQuality quality) Line 276   C++
    libcef.dll!cc::SoftwareImageDecodeCache::GetScaledImageDecode(const cc::ImageDecodeCacheKey & key, sk_sp<SkImage const > image) Line 704   C++
    libcef.dll!cc::SoftwareImageDecodeCache::DecodeImageInternal(const cc::ImageDecodeCacheKey & key, const cc::DrawImage & draw_image) Line 446   C++
    libcef.dll!cc::SoftwareImageDecodeCache::DecodeImage(const cc::ImageDecodeCacheKey & key, const cc::DrawImage & image, cc::SoftwareImageDecodeCache::DecodeTaskType task_type) Line 395   C++
    libcef.dll!cc::`anonymous namespace'::ImageDecodeTaskImpl::RunOnWorkerThread() Line 115   C++
    libcef.dll!content::CategorizedWorkerPool::RunTaskInCategoryWithLockAcquired(cc::TaskCategory category) Line 360   C++
    libcef.dll!content::CategorizedWorkerPool::RunTaskWithLockAcquired(const std::vector<enum cc::TaskCategory,std::allocator<enum cc::TaskCategory> > & categories) Line 339   C++
    libcef.dll!content::CategorizedWorkerPool::Run(const std::vector<enum cc::TaskCategory,std::allocator<enum cc::TaskCategory> > & categories, base::ConditionVariable * has_ready_to_run_tasks_cv) Line 230   C++
    libcef.dll!content::`anonymous namespace'::CategorizedWorkerPoolThread::Run() Line 35   C++
    libcef.dll!base::SimpleThread::ThreadMain() Line 69   C++
    libcef.dll!base::`anonymous namespace'::ThreadFunc(void * params) Line 86   C++
    kernel32.dll!@BaseThreadInitThunk@12()   Unknown
    ntdll.dll!__RtlUserThreadStart()   Unknown
    ntdll.dll!__RtlUserThreadStart@8()   Unknown


I can also gather/provide whatever additional information might be useful; please just ask, and I will respond right away.

Not sure if this is a possible bug? Or if there are command line arguments I might provide to avoid this exception?

Any insight would be appreciated. Thank you!

[magreenblatt]

Does the problem reproduce with cefclient? Try upgrading to a supported CEF version: https://bitbucket.org/chromiumembedded/ ... -supported

[mgteg]

I am able to reproduce the problem consistently, using both chromium v55 and v57.

However, reproduction requires the .NET wrapper provided by CefSharp, which uses chromium v57 at this time.

Is there any other information I can gather that might be useful here? (Stack trace from chromium v55, diagnostic log from either v55 or v57, etc.)

[magreenblatt]

Since you're using a 32-bit build are you enabling large address awareness? The linker setting is https://msdn.microsoft.com/en-us/library/wz223b1z.aspx

[amaitland]

The default x86 SubProcess shipped with CefSharp is large address aware.

[mgteg]

So far I am having good results when I enable LAA on my executable. I have a load-testing routine that fails after ~25 seconds without LAA, but ran for several hours with LAA.

The test puts a few thousand markers on a google map, then performs animated zooming and panning operations around the map. The marker locations and animations are not random, so the test is consistent each run.

I am going to test my application with top-down memory addresses today, just to make sure all of the libraries in the application can handle the LAA flag.

I will report back with my findings.

Thanks!

[mgteg]

I tested the application with LAA and top-down memory addresses; no issues.

The application will be deployed to a group of test users over the next few days. I will report back with results.

[guiqulai]

@mgteg The application with LAA is the main application which start cefsharp subprocess.exe?

[mgteg]

@guiqulai Yes correct, I added LAA to my main application exe.

Also, so far so good on my end. The application was successfully deployed to a group of test users who experienced no problems for over two weeks. Previously, these test users were reporting frequent crashes, multiple times per day.

The application is now available for our general users, who have reported no problems.