search for: _dl_relocate_object

...th produced by lld). The results are interesting: % grep -v '^#' perf-gnu/perf.report-by-dso-sym | head 38.77% ld-2.24.so [.] do_lookup_x 8.08% ld-2.24.so [.] strcmp 2.66% ld-2.24.so [.] _dl_relocate_object 2.58% ld-2.24.so [.] _dl_lookup_symbol_x 1.85% ld-2.24.so [.] _dl_name_match_p 1.46% [kernel.kallsyms] [k] copy_page 1.38% ld-2.24.so [.] _dl_map_object 1.30% [...

...information in 32bit DLL 'GDI32.DLL' (0x40904000) No debug information in 32bit DLL 'USER32.DLL' (0x409a3000) Unhandled exception: page fault on read access to 0x4196e734 in 32-bit code (0x4000ad3d). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x4000ad3d (_dl_relocate_object+0x32d [dl-reloc.c:92] in ld-linux.so.2): movw 0x0(%esi,%eax,2),%cx Enter path to file '/home/jkreager/d/src/glibc-2.2.3/elf/dl-reloc.c': Unable to open file /dl-reloc.c Wine-dbg>

...library(ssOptim) Segmentation fault (core dumped) This library works fine in R-0.65.1 running under RedHat 6.1 on a variety of systems, and also works fine in R-1.0.1 under Solaris 5.1. My suspicion is something to do with RedHat 6.2. Using gdb (with my limited skills) shows the problem to be in: _dl_relocate_object (...) at ../sysdeps/i386/dl-machine.h:326 This symbol is to be found in /lib/ld-2.1.3.so. I wondered if this might have been a duplicate symbol, but I think I have eliminated that problem (using nm). I guess my next test is to try it with RedHat 6.1 (but I am fearful that RH6.1 won't install...

...12372== by 0x48024E8: _vgnU_freeres (vg_preloaded.c:62) ==12372== by 0x3EAB60D33B: _dl_signal_error (in /lib64/ld-2.5.so) ==12372== by 0x3EAB60D3D3: _dl_signal_cerror (in /lib64/ld-2.5.so) ==12372== by 0x3EAB609CEF: _dl_lookup_symbol_x (in /lib64/ld-2.5.so) ==12372== by 0x3EAB60A9D4: _dl_relocate_object (in /lib64/ld-2.5.so) ==12372== by 0x3EAB603629: dl_main (in /lib64/ld-2.5.so) ==12372== by 0x3EAB6134EA: _dl_sysdep_start (in /lib64/ld-2.5.so) ==12372== by 0x3EAB601389: _dl_start (in /lib64/ld-2.5.so) ==12372== by 0x3EAB600A77: ??? (in /lib64/ld-2.5.so) ==12372== Address 0x0 is not...

...ymbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /usr/lib/libjpeg.so.62...done. Reading symbols from /usr/lib/libpng.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Reading symbols from /usr/local/src/R-1.1.1/library/eda/libs/eda.so...done. #0 0x40009634 in _dl_relocate_object (l=0x81e73b0, scope=0x81e75b4, lazy=0, consider_profiling=0) at ../sysdeps/i386/dl-machine.h:326 326 ../sysdeps/i386/dl-machine.h: No such file or directory. (gdb) quit -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien...

> On October 21, 2016 at 6:27 AM Tamsy <dovecot-list at mohtex.net> wrote: > > > Timo Sirainen wrote on 20.10.2016 04:01: > > http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz > > http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz.sig > > > > There are quite a lot of changes since v2.2.25. Please try out this RC so we can get a good

...-2.28.so [.] __strchr_sse2 0.06% script/public-i perl [.] Perl_call_sv 0.06% /mnt/btr/public perl [.] Perl_pp_nextstate 0.06% perl perl [.] Perl_ck_stringify 0.06% /mnt/btr/public ld-2.28.so [.] _dl_relocate_object 0.06% /mnt/btr/public perl [.] Perl_runops_standard 0.06% script/public-i perl [.] Perl_pp_pushmark 0.06% /mnt/btr/public perl [.] Perl_re_op_compile 0.06% script/public-i libxapian.so.30.8.0 [.] Xapian::Internal::QueryTer...

Going back to the "prioritizing aggregated DBs" thread from February 2020, I've got 390 Xapian shards for 130 public inboxes I want to search against(*). There's more on the horizon (we're expecting tens of thousands of public inboxes). After bumping RLIMIT_NOFILE and running ->add_database a bunch, the actual queries seem to be taking ~30s (not good :x). Now I'm

Full_Name: Massimo santini Version: 1.0.1 OS: Linux Submission from: (NULL) (159.149.147.89) I've just dl the .rpm of R 1.0.1, installed it and then launched insatll.packages("akima") after re-launching R [--vanilla], the command library(akima) has the only effect to coredump the program. Here is the output of gdb and strace... --- GDB (commands given can be seen from the

hi all after getting some (or - a lot) of messages from nagios, claiming asterisk to be down, I found this out... astping xxx times repeatedly, and the manager fails to start. this little script was used for testing. below, I've pasted the output from 'ps axfv' before and after the DoS, showing asterisk having allocated ~2GB RAM. roy #!/usr/bin/perl -w use strict; my $i = 0;

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

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports