similar to: lldb stops on every call to dlopen

[+lldb-dev] Hello Steve, thanks for the report. The fact that you see the rendezvous breakpoint being hit many times is not surprising. We get those every time the library is loaded (we need that to load relevant debug info and set potential breakpoints). However, they should generally not be surfaced to the user (unless you have the stop-on-sharedlibrary-events setting set, which you

It is interesting that the stop reason on the thread that stopped is "trace". That's what you would expect returning from the single-step to step over the breakpoint. But it looks like we got a signal while single-stepping, but the stop reason was misreported by somebody. Jim > On Apr 17, 2018, at 6:00 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:

Hi Nick, --start-group/--end-group functionality with the Gnu flavor currently works only if the --start-group/--end-group contains archive files. If they contain dynamic libraries, the undefined atoms from the dynamic libraries are processed whenever the group is iterated again. I am trying to find out a way to make the resolver add undefined atoms from the shared library only *once*, when

I've run into some issues with the current atom object model that I would like to fix. The current 4 atoms are not expressive enough. We need to be able to serialize a larger set of atoms, many of which are format specific. The set of common atoms (shared between all formats) should be the set that the resolver requires to work. SharedLibrary is not included in this (by looking at the source

I'd do that with the nextFile abstraction like this: On the first iteration, a Group would return its member every time getNextFile() is called (the same as the current behavior). On the second and further iterations, the Group should skip all the members whose type is not Archive. By doing this, the core linker sees dynamic libraries (or regular object files) only once even if they are in

Hi Rui, I thought about this, but there is a catch. The undefined symbols still need to be resolved with exports from dynamic libraries even the second time, or any number of times. For example :- ld 1.o --start-group libc.so myprintf.a --end-group 1.o has a undef for myprintf, which is in myprintf.a and myprintf.a calls puts. The first time when libc.so, undef atoms would be added, no

Hi, We are rebasing our audio compression subsystem using OPUS rather than SPEEX. The platform is Android but this piece is written in C code: we need to support armv5/armv7/x86 architectures.... and we use the released opus-1.1beta package from here<http://downloads.xiph.org/releases/opus/opus-1.1-beta.tar.gz>. A lot of our OPUS build system + code to drive the audio compression has been

On Jul 18, 2012, at 3:41 PM, Clow, Marshall wrote: > On Jul 18, 2012, at 2:34 PM, Nick Kledzik wrote: >> On Jul 18, 2012, at 12:52 PM, Michael Spencer wrote: >>> I've run into some issues with the current atom object model that I >>> would like to fix. >>> >>> The current 4 atoms are not expressive enough. We need to be able to >>>

http://bugzilla.netfilter.org/show_bug.cgi?id=741 Summary: ULOGD segfaults on init Product: ulogd Version: SVN (please provide timestamp) Platform: i386 OS/Version: other Status: NEW Severity: blocker Priority: P5 Component: ulogd_MYSQL AssignedTo: netfilter-buglog at lists.netfilter.org

[root at mems ~]# valgrind --leak-check=full --show-leak-kinds=all -v ping google.com ==3135== Memcheck, a memory error detector ==3135== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==3135== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==3135== Command: ping google.com ==3135== --3135-- Valgrind options: --3135-- --leak-check=full --3135--

WINS nsswitch module -------------------- The WINS nsswitch module has been rewritten to address memory issues and to simplify the code. The module now uses libwbclient to do WINS queries. This means that winbind needs to be running in order to resolve WINS names using the nss_wins module. This does not affect smbd. my problem: old versions >> ping google.com >> PING google.com

Sorry for the uninformative subject line; I can't think of a short way to describe the problem. I installed Wine on a Debian Sarge machine. I installed Wine version 0.9.25 from backports.org, since the version in Sarge proper is way too old. Then I tried to configure Wine using winecfg, but that didn't work out: I only got this output (abbreviated; I can send the full output if

Dear all, I was trying to use the R swig wrapper with R 2.7 and shogun ( http://www.shogun-toolbox.org ) but it fails completely, as in doesn't even compile and even after patching then though compiling - crashes... So I asked on swig-users/swig-devel CC'ing the potential R maintainer but I never received a reply. I now wonder if anyone here could help or would be willing to maintain

Help me how to config wine on slackware 11?

root at memorex:~# winecfg wine: glibc >= 2.3 without NPTL or TLS is not a supported combination. It will most likely crash. Please upgrade to a glibc with NPTL support. wine: creating configuration directory '/root/.wine'... wine: glibc >= 2.3 without NPTL or TLS is not a supported combination. It will most likely crash. Please upgrade to a glibc with NPTL support. wine:

I get the errors: zip4_lnx.a(generic.o)(.text+0xb16): more undefined references to `__ctype_b' follow zip4_lnx.a(libdl.so): undefined reference to `_dl_close at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_catch_error at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_addr at GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to

Hi, Probably some of the leaks Valgrind reports are spurious, but the numbers seem to be significant enough to demand some attention: ==10132== LEAK SUMMARY: ==10132== definitely lost: 15,624 bytes in 558 blocks. ==10132== indirectly lost: 44,548 bytes in 1,591 blocks. ==10132== possibly lost: 37,576 bytes in 98 blocks. ==10132== still reachable: 1,336,876 bytes in 1,364 blocks.

Hi, I'm trying to get Half-Life to run under Linux with wine, which is allegedly possible... I'm running debian unstable and don't have a windows partition. I installed wine from cvs from cvs.winehq.com:/home/wine, and ran the ./tools/wineinstall script, following the instructions on the howto here: http://lhl.linuxgames.com/howto/half-life-HOWTO-0.4.1.html I get to the part

I'm getting a segfault when I call `SDL_Init( SDL_INIT_VIDEO )` within the MCJIT.  If I compile the same program to an EXE I don't have a problem. Are there any general restrictions, or known issues, with loading a library like SDL2 via the MCJIT?  (LLVM-3.8 still) The stack trace, from GDB, is below. I noticed the error actually happens deep inside a transitively loaded GL drive module,

I am using LLVM version 4.0.1 Running `llc -march=riscv64 math.ll` returns: #0 0x0000000000fed7d1 (llc+0xfed7d1) #1 0x0000000000fec559 (llc+0xfec559) #2 0x0000000000fec8d9 (llc+0xfec8d9) #3 0x00007f22c044e5e0 __restore_rt (/lib64/libpthread.so.0+0xf5e0) #4 0x0000000000d7faf3 (llc+0xd7faf3) #5 0x0000000000cd4b88 (llc+0xcd4b88) #6 0x0000000000cd530c (llc+0xcd530c) #7 0x00000000006858c3