I'm using address sanitizer (ASAN) with visual studio 2019 (version 16.9.2) on windows.
ASAN is reporting lots of errors and almost all of them are memcpy-param-overlap.
They are related usage of std::string.
==13388==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x2141a3ba,0x2141a3cb) and [0x2141a3b0, 0x2141a3c1) overlap
#1 0x16d3e32 in std::basic_string<char,std::char_traits<char>,std::allocator<char> >::insert C:\VS2019\VC\Tools\MSVC\14.25.28610\include\xstring:3006
#2 0x16ae413 in std::operator+<char,std::char_traits<char>,std::allocator<char> > C:\VS2019\VC\Tools\MSVC\14.25.28610\include\xstring:4346
Here is another instance
==13388==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x214239ba,0x214239cb) and [0x214239b0, 0x214239c1) overlap
#1 0x16d3e32 in std::basic_string<char,std::char_traits<char>,std::allocator<char> >::insert C:\VS2019\VC\Tools\MSVC\14.25.28610\include\xstring:3006
#2 0x16ae413 in std::operator+<char,std::char_traits<char>,std::allocator<char> > C:\VS2019\VC\Tools\MSVC\14.25.28610\include\xstring:4346
There are lots of these and all the errors are similar to above.
I don't know what I'm missing here. Is this related to std libraries.
Any hints/direction would be helpful.
Related
Problem running Plotly.NET on F# Interactive. (VS2019, FSharp Core 7.0.0, Plotly.NET 3.0.1, TargetFramework: net472)
#r C:\....\.nuget\packages\plotly.net\3.0.1\lib\netstandard2.0\Plotly.NET.dll"
open Plotly.NET
let xData = [0. .. 10.]
let yData = [0. .. 10.]
let myFirstChart = Chart.Point(xData,yData)
Gives an error: " C:\...\AppData\Local\Temp\1\unknown(1,1): error FS3216: type 'Plotly.NET.GenericChart+GenericChart' not found in assembly 'Plotly.NET, Version=3.0.0.0, Culture=neutral, PublicKeyToken=.......'. A possible cause may be a version incompatibility. You may need to explicitly reference the correct version of this assembly to allow all referenced components to use the correct version."
What should be correct configuration for environment to get that running?
I'm not sure why you mention "TargetFramework: net472". Also I'm puzzled by your mention of "FSharp Core 7.0.0", since F# interactive is going to be tied to some specific version of F#, for VS 2019 that won't be 7.0.
It's better to use the new syntax for referencing a nuget package from a script:
#r "nuget: Plotly.NET"
I tried your code in VS 2019 (referencing the nuget package as above) and still got a weird error. I then went to Tools | Options | F# Tools | F# interactive and changed the option "Use .NET Core Scripting" from false to true. I then reset the F# interactive session to make the change take effect, and tried your code again, and it worked.
> let myFirstChart = Chart.Point(xData,yData);;
Binding session to 'C:/Users/jimfo/.nuget/packages/plotly.net/3.0.1/lib/netstandard2.0/Plotly.NET.dll'...
Binding session to 'C:/Users/jimfo/.nuget/packages/dynamicobj/2.0.0/lib/netstandard2.0/DynamicObj.dll'...
val myFirstChart: GenericChart.GenericChart =
Chart
(Plotly.NET.Trace2D, Plotly.NET.Layout, Plotly.NET.Config,
Plotly.NET.DisplayOptions)
I didn't bother testing 32 bit vs 64 bit or seeing what happens in VS 2022.
I don't know what the errors are about, I have seen some strange errors lately given the mix of F# compiler versions, FSharp.Core versions, VS versions (think of all the patched versions), and sometimes you have to just fool around a bit until you get the right combination that works.
As already answered in this question:
JVM_FindSignal function continuously allocates native memory
jemalloc reporting leaks from JVM_FindSignal is related to missing debug symbols. I certainly have debugging symbols installed, see:
rbs42#rbs42-VirtualBox:/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server$ gdb libjvm.so -ex 'info address UseG1GC'
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from libjvm.so...
Reading symbols from /usr/lib/debug/.build-id/16/240e0172c3fc0dd6e974325c8ad1d93723ccac.debug...
(No debugging symbols found in /usr/lib/debug/.build-id/16/240e0172c3fc0dd6e974325c8ad1d93723ccac.debug)
Installing openjdk unwinder
Traceback (most recent call last):
File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 52, in <module>
class Types(object):
File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 66, in Types
nmethodp_t = gdb.lookup_type('nmethod').pointer()
gdb.error: No type named nmethod.
Symbol "UseG1GC" is at 0xd189b2 in a file compiled without debugging.
still my jeprof output looks as following:
rbs42#rbs42-VirtualBox:/media/rbs42/data/Gebos/RBS42/run/sms50$ jeprof --show_bytes /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java jeprof.22104.0.f.heap
Using local file /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java.
Using local file jeprof.22104.0.f.heap.
Welcome to jeprof! For help, type 'help'.
(jeprof) top
Total: 33502504 B
20958503 62.6% 62.6% 21342909 63.7% JVM_FindSignal
8388608 25.0% 87.6% 8388608 25.0% SNX11B1A
1481379 4.4% 92.0% 1481379 4.4% inflate
1151253 3.4% 95.5% 1151253 3.4% Java_java_util_zip_ZipFile_getZipMessage
426303 1.3% 96.7% 426303 1.3% SNE00B1A
404065 1.2% 97.9% 404065 1.2% inflateInit2_
253077 0.8% 98.7% 20393297 60.9% SUNWprivate_1.1
176271 0.5% 99.2% 176271 0.5% std::__throw_ios_failure
131713 0.4% 99.6% 131713 0.4% _dl_new_object
131328 0.4% 100.0% 131328 0.4% _dl_check_map_versions
(jeprof)
Is there anything else to consider?
It turns out that
openjdk-8-dbg package installs files with debug symbols into /usr/lib/debug/.build-id
jeprof looks for debug symbols in /usr/lib/debug/{FULL_SO_PATH}
So, it's a combination of a bug in jeprof that does not parse .note.gnu.build-id section, and a problem of the dbg package that does not include full path symlinks to debug libraries.
To work around this, you may create the corresponding symlink manually:
ln -s /usr/lib/debug/.build-id/16/240e0172c3fc0dd6e974325c8ad1d93723ccac.debug /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so
(the file names are taken from gdb output)
However, even when jeprof is able to read debug symbols, this doesn't often help in case of Java applications. The problem is that jemalloc doesn't know how to unwind Java stacks. See this presentation for an example.
Consider trying async-profiler that can show mixed Java+native stacks. Profiling malloc, mprotect and mmap calls with async-profiler can be helpful in finding native memory leaks in Java applications. See this answer for details.
Here is a patch for jeprof that makes it smarter about finding debug symbols. It's based on #apangin's answer.
https://github.com/jemalloc/jemalloc/pull/2059/files
If I compile some code with the following:
#include <string_view>
std::string_view strv{ "Test 1" };
I get this error:
Error C2065 'string_view': undeclared identifier...
I tried some other c++17 code and not of it works.
I get the same errors if the C++ Language Standard is set to std:c++14
The Properties-->C/C++-->Command line contains /std:c++17
but the actual compiler command line that runs does not have this option set.
This is a community version of Visual Studio 2019 version 16.7.1
user dxiv pointed out the problem is in the Property pages Platform pulldown it should be set to ALL Platforms (or set C++17 individually for Win32 and x64 platforms).
While running one piece of code using Alea.cuBase I am getting a type initialization exception
let worker = Engine.workers.DefaultWorker
System.TypeInitializationException was unhandled
Message: The type initializer for 'Worker' threw an exception.
I am using
visual studio 2012
.Net frame work 4.0
F# 3.1
Another piece of code I tried and got the same error at,
useprogram = template |> Compiler.loadWorker.Default
I started with trial version of Alea.cuBase 1.3.914.
Guide me how to fix this..
Problem got resolved.
My pc was having graphics card quadro fx 1800.
Because Alea cuBase support fermi or higher architecture.
When I tried with k4000 I could run the same program.
I am trying to compare the performance of a specific F# benchmark running on .NET and Mono 2.10.2 (Windows 7, 64-bit). I took the Spectral-Norm benchmark from the Benchmarks Game followed the traditional SO advice of using System.Diagnostics.StopWatch for benchmarking C# and added the lines 4, 89-90, and 93-95 at this link. I compiled this code in Visual Studio 2010 (For runtime 4.0, not client profile, any CPU, with optimize code and tail calls turned on). The compiled code runs just fine on .NET (including inside VS), but when I run the .exe on Mono with "mono shootout_spectralnorm.exe" I get the following error (repeated in the fssnip.net link):
Unhandled Exception: System.TypeInitializationException: An exception was thrown
by the type initializer for System.Diagnostics.Stopwatch ---> System.InvalidPro
gramException: Invalid IL code in System.Diagnostics.Stopwatch:.cctor (): method
body is empty.
--- End of inner exception stack trace ---
at Program.main (System.String[] args) [0x00000] in <filename unknown>:0
The strange thing is, when I remove the lines I had added (lines 4, 89-90, and 93-95, which relate to the timing part of the benchmark), the error goes away on Mono, and it acts just like it does on MS .NET. This is just baffling me. I set all of the referenced assemblies in VS to be copied locally, so they should be visible to Mono, but there could be some precedence issue with different assemblies in the GAC that have the same name as the ones in the local folder. Has anyone encountered this issue or a similar one, especially on Windows Mono? If so, or if you think you know how this problem could be fixed, I hope you can help me resolve it.
Reference Assemblies do not (often) have code - they are API signatures only (enough info for the compiler to reference them at design-time/compile-time). You need to copy the runtime assemblies, not the reference assemblies, in order to run it. (You'll often find the runtime assemblies in the GAC.)
Here are measurements for FSharp-2.0.0.0 spectral-norm #2 (Intel Q6600 quad-core, MS Vista 32 bit)
fsc CPU s Elapsed s
500 0.281 0.337
3000 4.883 1.453
5500 15.85 4.212
2.10.2 CPU s Elapsed s
500 0.343 2.222
3000 4.836 3.361
5500 15.912 6.153
C:/Mono-2.10.2/bin/mono.exe C:/FSharp-2.0.0.0/bin/fsc.exe --platform:x86
--optimize+ --out:spectralnorm.exe spectralnorm.fsharpmono-2.fs
C:/Mono-2.10.2/bin/mono.exe --gc=sgen spectralnorm.exe 5500
Now the benchmarks game spectral-norm on MS Vista demo, includes F# on Mono.