similar to: SIGSEGV (Segmentation fault) with antispam plugin

Hi all. This has been bugging me for quite some time and I haven't found a solution yet. I was wondering if anyone has any experience with similar scenarios or/and can tell me how this process can be optimized. We use rsync to synchronize JAR libraries on our remote server. The catch here is, that the libraries must go in multiple locations (and not all the locations have all the

On my system, I''m getting SIGSEGVs in xentop because xenstat_node_domain() is returning NULL. Skip the loop if it does rather than crashing. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff -r 9dda78d7af3b -r 5895ad758076 tools/xenstat/libxenstat/src/xenstat_linux.c --- a/tools/xenstat/libxenstat/src/xenstat_linux.c Tue May 18 15:38:36 2010 -0700 +++

http://bugs.freedesktop.org/show_bug.cgi?id=21908 Summary: SIGSEGV when no kernel DRM present Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

It seemed I found possible llvm-g++ bug. Programs compiled with llvm-g++ 4.5 crashed with SIGSEGV during stack unwinding in such testcase: chaos at chaos-desktop ~ % g++ --version g++ (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1 chaos at chaos-desktop ~ % echo "struct X{ ~X(){} }; int main() { X x; throw 1; }" > test.cpp && g++ test.cpp && ./a.out terminate called after

Hi Chaos A.D., > It seemed I found possible llvm-g++ bug. > Programs compiled with llvm-g++ 4.5 crashed with SIGSEGV during stack unwinding > in such testcase: I can reproduce this - investigating. Ciao, Duncan.

Hi! I have a problem that i dont know how to tackle ... i have done kickstarting many times but know it seems i hit an wall ... i try to kickstart through nfs an 64 bit centos .. just after taking ip trough dhcp i receive an SIGSEGV ! i dont know what to do anymore as the same ks.cfg worked very well until now .. Many thanks! Adrian -------------- next part -------------- A non-text attachment

Reading symbols from /usr/lib/dovecot/auth...Reading symbols from /usr/lib/debug//usr/lib/dovecot/auth...done. done. Attaching to program: /usr/lib/dovecot/auth, process 29099 [New LWP 29099] Core was generated by `dovecot/auth'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f40b534c418 in array_append_i (count=<optimized out>, data=<optimized out>,

Hey, you mentioned that dovecot builds fine, but does "make check" also complete successfully with a glibc-2.28 build on a glibc-2.28 system? We have been seeing segfaults during "make check" and it seems the following patch was able to make the testsuite run successfully. Just out of curiosity, could you try this patch and see if this fixes the issues you're

https://bugzilla.samba.org/show_bug.cgi?id=10776 Summary: SIGSEGV in utf8_internal_loop() Product: rsync Version: 3.1.0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org ReportedBy: mluscon at redhat.com

That's definitely strange and I've never encountered that. Normally, the only way for _mm_load_ups to generate a segfault is for the input to be invalid memory, in which case the C version should crash too. I suspect the compiler (or something else) may be hiding the real problem. Can you get a debugger and see exactly what assembly statement is causing the crash and what the operands are?

> I've seen the exact same in my version (mingw on win32), and the problem > was that the stack was misaligned when entering the function, so the temp > registers weren't at 16-byte boundries. That's a possibility. It's easy to check by printing the address of the variables. I know that gcc 3.3 had some alignment issues with _m128 that were supposed to be fixed in

>> I've seen the exact same in my version (mingw on win32), and the problem >> was that the stack was misaligned when entering the function, so the temp >> registers weren't at 16-byte boundries. > > That's a possibility. It's easy to check by printing the address of the > variables. I know that gcc 3.3 had some alignment issues with _m128 that > were

Tom, Thorvald, Could one of you submit the details to the gcc bugzilla so it gets fixed? BTW, is 4.0 affected? Jean-Marc Le vendredi 06 janvier 2006 ? 17:13 -0800, Tom Harper a ?crit : > Thorvald, > > re: > At 03:18 AM 1/6/2006, Thorvald Natvig wrote: > >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... > >And the addresses were not properly

This behaviour is confirmed for RH70, RH62, Debian 2.2 on 3 different Pentium-class i386. I've checked back and package ann_0.2-2 works on 1.1.1, but fails with seg. faults on 1.2.0 (ann_0.2-2.pre3.tar.gz to accommodate the change in Makeconf) and subsequent (1.2.0 checked today on RH62 with gcc 2.95.3 19991030 (prerelease)). It is most likely that 1.1.1 was too forgiving, and that better

It looks as though the problem isn't in R - I provoked a SIGSEGV under R 1.1.1 on RH62: > for (i in 1:100) an1 <- ann(cbind(runif(1000), runif(1000)), k = 4) > for (i in 1:100) an1 <- ann(cbind(runif(1001), runif(1001)), k = 4) Program received signal SIGSEGV, Segmentation fault. 0x40111109 in chunk_free (ar_ptr=0x401a5d40, p=0x8849a30) at malloc.c:3111 3111 malloc.c: No such

On Thu, 9 Aug 2018, Dirk Eddelbuettel wrote: > > On 9 August 2018 at 20:37, Tomas Kalibera wrote: > | So to answer your original question, this could probably be handled in > | Rcpp, > > Hm. Why do you say that / what did you have in mind? We say it because it is true. Rcpp registers C finalizers and running them after unloading will segfault. For now it would be better for

I am running Samba version 2.0.6 on Solaris 2.6. When I run smbstatus, it coredumps. Here is some detailed information that may help in killing this bug. This is a run of smbstatus where it coredumps, and afterwards, a gdb session. root@grads:/depot/samba-2.0.6/bin 174# ./smbstatus Samba version 2.0.6 Service uid gid pid machine ----------------------------------------------

Hello, I have compiled rsync 2.5.0 cleanly on a Solaris 2.6 box, and can use the resultant binary as a client with no problem. However, when I try and start a daemon, it exits with exit code 0, and no daemon running. I have previously run 2.4.6 and other versions with the same rsyncd.conf file, but can't seem to get the daemon up with 2.5.0. A truss shows the following: # truss -f

https://bugzilla.netfilter.org/show_bug.cgi?id=1190 Bug ID: 1190 Summary: adding element to map with stateful object and flag interval raise SIGSEGV Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: normal Priority: P5 Component:

Hi Ryan, > Does anyone happen to know why the ustack() doesn''t show lex, > yak, main > and _start? A quick look with the source browser seems to indicate that _rt_boot is code executed very early in the lifetime of your process by ld.so.1. What seems to be happening is that ld.so.1 has allocated some memory before DTrace got control of your process - long before main() was