Bug 22273 - Getting SIGABRT in object.AllocString
Summary: Getting SIGABRT in object.AllocString
Status: RESOLVED NOT_REPRODUCIBLE
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-08-21 18:02 UTC by Artyom Antyipin
Modified: 2017-07-12 22:54 UTC (History)
6 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
crash stacktraces (52.50 KB, text/plain)
2014-08-21 18:02 UTC, Artyom Antyipin
Details
Test program (2.89 KB, application/x-gzip)
2014-08-29 18:24 UTC, Artyom Antyipin
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NOT_REPRODUCIBLE

Description Artyom Antyipin 2014-08-21 18:02:07 UTC
I have relatively small program in F# which serves small files through libevent interop library. It also uses EntityFramework 6 to access file metadata stored in mysql library.
Problem is that is reproducibly crashes after ~25000 requests. Crash always comes from getting SIGABRT in Object.AllocString (see attachment for full stacktraces).

---
The configuration follows:
CentOS 6.5 (but the problem is also reproducible on Ubuntu 14.04)
$ mono-sgen --version
Mono JIT compiler version 3.4.0 (mono-3.4.0-branch/954ed3c 2014. aug. 14., csütörtök, 12.04.32 CEST)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.4svn-mono-mono/e656cac)
	GC:            sgen
Comment 1 Artyom Antyipin 2014-08-21 18:02:47 UTC
Created attachment 7764 [details]
crash stacktraces
Comment 2 Zoltan Varga 2014-08-22 20:28:50 UTC
Please try mono 3.6.0, many gc bugs very fixed since 3.4.
Comment 3 Rodrigo Kumpera 2014-08-25 23:49:53 UTC
Does it happen with mono 3.8?
Comment 4 Artyom Antyipin 2014-08-29 18:23:17 UTC
Yes it does happen with both 3.6 and 3.8.

Furthermore I've found out that the leak only happens when using EntityFramework to query any data (both entities and strings).

I've written simple program (attachment follows) using NuGet packages (EntityFramework6 and MySql.Data.EF6) which creates a single table, inserts some value into it, then selects the inserted values in infinite loop. GC.Collect is called explicitely every 200 iterations.

I've written 2 logically identical Action-s -- one using F# query statement, one using direct sql command both on the same DbContext object.

When running the "direct" version -- Memory usage remains a constant. But with the "query" version the memory usage increases monotonically.
(When started with "ef" as an argument the program uses "query", otherwise -- "direct" action)

My system:
Ubuntu Trusty (14.04) uptodate
kernel: 3.13.0-35-generic
Mono: mono-3.8.0-branch 356dbc5 [corlib] Task never is CompletedSynchronously
Mono JIT compiler version 3.8.0 (mono-3.8.0-branch/356dbc5 2014. aug. 29., péntek, 08.36.06 CEST)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.4svn-mono-mono/e656cac)
	GC:            sgen
F#: master    20a9d20 add change note (3.1)
Comment 5 Artyom Antyipin 2014-08-29 18:24:33 UTC
Created attachment 7875 [details]
Test program
Comment 6 Zoltan Varga 2014-08-29 19:16:11 UTC
This could be a runtime leak or a leak in the class libs.
Comment 7 Artyom Antyipin 2014-08-30 16:34:27 UTC
Digging furthermore gave me the following results:
Creating System.Linq.Expression-s and passing them to Queriable.XXX(..) directly does not increase memory.
AND GC reported memory always reports the same amount of memory, so it is not GC-related bug.
Still memory usage grows monotonically when using Microsoft.FSharp.Linq.QueryBuilder.

- pmap-ing the process shows that lots of small "anon" chunks of memory are allocated. 
- in F# source code I can see that each use of query { ... } results in compiling linq expression (src/fsharp/FSharp.Core/Linq.fs:795).

It seems that the bug is not directly related to GC but to freeing JIT compiled linq expressions. It seems that they stay forever in memory -- producing a memory leak.

I've tried the same code on windows/.NET machine and I could not reproduce the leak there (the dynamically compiled code blocks seems to be freed when no longer needed).

I think it is definitely a bug in mono runtime that makes usage of f# version of linq very problematic (almost unusable) on mono.
Comment 8 Ludovic Henry 2017-07-12 22:54:39 UTC
Can you still reproduce with latest version of mono? If you can, please reopen the bug. Thank you