Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited
On Thu, 23 Feb 2012 18:45:29 +0530 Desai, Kashyap kashyap.de...@lsi.com wrote: -Original Message- From: Ed Schouten [mailto:e...@80386.nl] Sent: Thursday, February 23, 2012 3:16 PM To: Desai, Kashyap Cc: freebsd-s...@freebsd.org; freebsd-stable; jo...@freebsd.org; Kenneth D. Merry; McConnell, Stephen; Justin T. Gibbs Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Hi Kashyap, * Desai, Kashyap kashyap.de...@lsi.com, 20120222 18:51: Adding Ed Schouten and Jorg Wunsch as I see there are author of msleep/mtx related APIs. Am I? :-) I am new to FreeBSD and desperate to know the answer. :-). Thanks for your help. 1. When any irq is register with FreeBSD OS, it sets TDP_NOSLEEPING pflag. It means though irq in freebsd is treated as thread, We cannot sleep in IRQ because of TDP_NOSLEEPING set. 2. In mps driver we have below code snippet in ISR routine. mps_dprint(sc, MPS_TRACE, %s\n, __func__); mps_lock(sc); mps_intr_locked(data); mps_unlock(sc); I wonder why there is no issue with above code ? Theoretical we cannot sleep in ISR. (as explained in #1) Any thoughts ? The TDP_NOSLEEPING flag only disallows sleeping of an indeterminate amount of time. Locking a mutex is allowed, as it can only cause the thread to be blocked for a small amount of time, waiting for another thread to unlock it. So does this assumption that another thread will release mutex fast enough ? Same as msleep() this can be applicable here as well. I mean another thread _can_ (if some bad drivers) take long time to release mutex. Bad drivers can just defererence wild pointer to satisfy their need for wrongdoing. For that reason let us keep them out of conversation. mtx locks were designed to protect small sections of code where thread is only allowed to block waiting for other thread to release the lock of similar class. While threads are blocked, they get benefit of adaptive sleep and priority propagation and should take precaution of never taking the path of code that can cause them to sleep. Assertions are there to help code authors with that. sleep locks are by definition unbound. There is no spinning, no priority propagation. Holders are free to take, say, page faults and go to long journey to disk and back, etc. Hardly the stuff _anyone_ would want to do from interrupt handler, thread or otherwise. 3. I recently added few place msleep() instead of DELAY in ISR context and I see Trying sleep, but thread marked as sleeping prohibited. Which makes sense, as msleep() can be used to sleep for indefinitely. This part is clear. ! I agree with all experts view. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ ___ freebsd-s...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to freebsd-scsi-unsubscr...@freebsd.org -- Alexander Kabaev signature.asc Description: PGP signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Wed, 04 Jan 2012 14:31:55 -0800 matt...@phoronix.com wrote: Thanks for the comment Arnaud. For comparative benchmarking on[1]Phoronix.com, Michael inva configuration 'in the way the developers or production'. This is by rule. However, i poor scores on be 'it should be tuned, is configured for a diffe The response from us to this comes in two forms. nb 1) If it is the wrong workload for the platform, do a public pos explaining and analysing the results. Highlighting the rationale fo r the concious reduction in performance (ie: journaling filesystems with ba filesystem integrity 2) If tuning can have a material impact on the results, post a t uning guide with step by step and rationale. Ie: educate the communit Michael and I have had many discussions with vendors an on this. In almost all cases, the vendor has either cha default configuration or accepted the results as valid. Asguide, Micha comparison. To dat offer. In part, thi public, but that is more of a result of a one sided d party external to a particular community (with a healthy tou journalisticly pumped compare contrast). For the FreeBSD community, who else outside of the FreeBSD community actually runs public c Matthew Not really related to the discussion on hand, but the above about the most unreadable email I am yet to read on the public mailing list. -- Alexander Kabaev signature.asc Description: PGP signature
Re: devel/subversion: svn: Couldn't perform atomic initialization
On Sun, 03 Jul 2011 11:15:50 +0200 Hartmann, O. ohart...@zedat.fu-berlin.de wrote: On 07/02/11 20:45, Alexander Kabaev wrote: On Sat, 02 Jul 2011 09:27:42 +0200 Hartmann, O.ohart...@zedat.fu-berlin.de wrote: SKIP/ Update database/sqlite3 port to the 3.7.7.1 version committed today. Done - and it works fine. Thanks. But why 3.7.7.1 and not 3.7.7.2? Thanks, anyway. Regards, Oliver No reason other than 3.7.7.1 appears to be the latest version currently in ports. -- Alexander Kabaev signature.asc Description: PGP signature
Re: devel/subversion: svn: Couldn't perform atomic initialization
On Sat, 02 Jul 2011 09:27:42 +0200 Hartmann, O. ohart...@zedat.fu-berlin.de wrote: Hello. Since two days now I realize on several recently ports-updated servers a failure of the subversion server running on those servers. Sneaking around the internet I found several issues exactly targeting this error with an sqlite 3.7.7/3.7.7.1 issue, which has been fixed in sqlite-3.7.7.2. At this very moment, our subversion servers in question has all recently been updated and it seems, they all fail the same way. Does anyone also realize this behaviour shown below when commiting? Is there a workaround? Any help or hint is appreciated. Thanks in advance, Oliver Transmitting file data .svn: Commit failed (details follow): svn: Couldn't perform atomic initialization svn: database schema has changed svn: Your commit message was left in a temporary file: Update database/sqlite3 port to the 3.7.7.1 version committed today. -- Alexander Kabaev signature.asc Description: PGP signature
Re: RFC vgrind in base (and buildworld)
On Thu, 20 Jan 2011 23:11:43 +0100 Ulrich Spörlein u...@freebsd.org wrote: On Thu, 20.01.2011 at 15:31:03 -0500, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Just to respond to initial comment, I can live without vgrind in base just fine, provided one cna be installed from ports (looks like that is true). -- Alexander Kabaev signature.asc Description: PGP signature
Re: RFC vgrind in base (and buildworld)
On Thu, 20 Jan 2011 17:11:13 -0800 Marcel Moolenaar xcl...@mac.com wrote: On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. Actually no. The buildtools target is there to allow building programs that are not installed, but are otehrwise needed to compile a program. These are typically little tools that create source files. The bootstrap target is the to deal with compatibility in case we can't use the version on the host or we don't want to depend on the version on the host. Then it is cross-tools, or whatever build stage that builds new gcc and other tools which run on host and are used to generate the final target binaries. The point being that bootstrap-tools target is greatly abused in src, with recent addition of llvm libs making it almost pandemic. -- Alexander Kabaev signature.asc Description: PGP signature
Re: RFC vgrind in base (and buildworld)
On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Build issue in libstdc++ at revision r216418
On Tue, 14 Dec 2010 01:21:37 +0100 Ollivier Robert robe...@keltia.net wrote: Just trying to update my 8.1-PRERELEASE to 8.2-PRERELEASE and it tumbles upon this error in libstdc++. Any idea? 2 -O -pipe -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. -frandom-seed=RepeatabilityConsideredGood -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c atomicity.cc atomicity.cc: In function '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)': atomicity.cc:36: error: redefinition of '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)' /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/ext/atomicity.h:50: error: '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)' previously defined here atomicity.cc: In function 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)': atomicity.cc:47: error: redefinition of 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)'/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/ext/atomicity.h:54: error: 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)' previously defined here *** Error code 1 Clean your obj, pretty please. Then do make cleandir couple of times in src. Then repeat your build. -- Alexander Kabaev signature.asc Description: PGP signature
Re: TTY task group scheduling
On Thu, 18 Nov 2010 18:56:35 + Alexander Best arun...@freebsd.org wrote: On Thu Nov 18 10, Matthew D. Fuller wrote: On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of Alexander Best, and lo! it spake thus: judging from the videos the changes are having a huge impact imo. Well, my (admittedly limited, and certainly anecdotal) experience is that Linux's interactive response when under heavy load was always much worse than FreeBSD's. So maybe that's just them catching up to where we already are ;) well...i tried playing back a 1080p vide files while doing `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfect. One thing that just begs to be asked: since when decoding 1080p became an interactive task? -- Alexander Kabaev signature.asc Description: PGP signature
Re: ionice in FreeBSD?
On Fri, 5 Feb 2010 09:25:55 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote: I appreciate your work on this -- truly I do -- but the above statement is incredible. This is not meant as a flame-inducer, but there's really no other way to phrase it: This IS NOT what production-ready means to the rest of us, particularly those of us in the server world. A single developer running such code on their workstation for a few months is in no way identical to that of a heavily I/O-bound server. I thought freebsd.org (or maybe ISC?) offered some test/development boxes on the 'net available to developers who could test such code + perform stress tests over long periods of time? I'm probably mistaken, but I was under that impression. Luigi wrote: i would say it is pretty solid. I used it on my main workstation and desktop for a few months last year without a glitch. In what twilight zone does that mean 'Yes, it is production ready' to warrant such a nice diatribe? -- Alexander Kabaev signature.asc Description: PGP signature
Re: status of flash9/flash10 support in RELENG_7 ?
On Sat, 25 Jul 2009 17:36:00 +0400 Boris Samorodov b...@ipt.ru wrote: As for the original question. I don't use flash so can't be very helpful here. But there are reports at emulation@ ML that both linux-f8-flashplugin10 and linux-f10-flashplugin10 work better then flashplugin[7|9]. It does not work very well under Linux32 compat on -current - our futex implementation seems to be too broken and causes frequent deadlock and causes multiple threads to get stuck on process exit. One can easily collect dozens of those stuck processes doing causal web browsing. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Failure to make world for RELENG_6_4
On Sun, 05 Apr 2009 19:09:57 -0700 Xin LI delp...@delphij.net wrote: - From what you have described, it's likely that there is some memory issue. The FreeBSD Virtual Memory system tends to use all physical memory and this could be a problem for faulty memory chips (i.e. it's more easy for FreeBSD to trigger problems). If you have access to the host system and possible, would you please try to install FreeBSD directly and see if the problem still occurs? Cheers, - -- Xin LI delp...@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve! JFYI, this seems to be the issue with combination of FreeBSD 6.x and VMWare hypervisor when running with more than one virtual CPUs. I see it will the full range of VMWare products, from Player to Fusion and Workstation. FreeBSD 7 and up are working fine. -- Alexander Kabaev ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: -m32 broken on bi-arch amd64 systems?
On Tue, 23 Dec 2008 17:36:08 +0100 Maciej Suszko mac...@suszko.eu wrote: Garrett Cooper yanef...@gmail.com wrote: Hi guys, I think I may have found an issue today with our bi-endian structure, and I wanted to make sure whether or not it was an already known issue (-m32 is broken for gcc with lib32/libgcc.a): [r...@fbsd-7-test]# gcc -o boo boo.c # Compiles [r...@fbsd-7-test]# gcc -m32 -o boo boo.c /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc [r...@fbsd-7-test]# file /usr/lib32/libgcc_s.so.1 /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, stripped [r...@fbsd-7-test]# uname -a FreeBSD fbsd-7-test.gateway.2wire.net 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sun Nov 23 16:19:09 UTC 2008 r...@fbsd-7-test.gateway.2wire.net:/usr/obj/usr/src/sys/STARR amd64 I wish I had my amd64 CURRENT machine in front of me to confirm this, but I don't. Please keep me CC'ed as I am not subscribed to either amd64@ or sta...@. Thanks! -Garrett I also noticed that behavior, shouldn't compiler/linker look into /usr/lib32 without additional -B switch? -- regards, Maciej Suszko. Read email archives, this was discussed on several occasions before. Short summary: it never worked and will not work unless some non-trivial work is put into how GCC handles include and linker search paths. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Help me to develop a FreeBSD patch for gcc-4.2.1
On Tue, 7 Oct 2008 20:25:03 -0700 (PDT) Unga [EMAIL PROTECTED] wrote: --- On Wed, 10/8/08, Alexander Kabaev [EMAIL PROTECTED] wrote: If you still have CVS tree available, you can do 'cvs diff -rFSF' in contrib/gcc and apply the patches to files gcc-4.2.1/gcc. Hi Alexander, thanks for the reply. I'm new to 'cvs diff -rFSF'. I need to do more home work before I try your method. Could you kindly confirm it work for you? after applying the patch, does your compilation of gcc complete cleanly? I get errors. Therefore, could you try it please. I'm waiting for your reply. Best regards Unga I never had a good reason to try, but it should compile with little or no extra work. Getting diff against vendor branch in CVS is much easier way than what you are doing anyway. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Help me to develop a FreeBSD patch for gcc-4.2.1
On Mon, 6 Oct 2008 06:19:34 -0700 (PDT) Unga [EMAIL PROTECTED] wrote: Hi all I need to patch the gcc original sources to suit the FreeBSD, specially to support FreeBSD kernel compilation. I have tried it, spent lot of time, but it still develops compilation errors. The FreeBSD stable comes with gcc-4.2.1 but the sources are scattered over the /usr/src, therefore, I find it difficult to re-create the gcc-4.2.1 to its original directory layout to make a patch. I appreciate it very much, if you guys could help me to identify the pieces. Or alternatively, if someone could straight away put the FreeBSD gcc sources back to a directory and make a patch compared to the original gcc-4.2.1 sources from GNU and post here, I could apply the patch on my side and verify it was done correctly, whether I can compile the FreeBSD kernel or not. Many thanks in advance. Kind regards Unga If you still have CVS tree available, you can do 'cvs diff -rFSF' in contrib/gcc and apply the patches to files gcc-4.2.1/gcc. -- Alexander Kabaev signature.asc Description: PGP signature
Re: threads cleanup?
On Thu, 24 Apr 2008 12:04:20 +0300 Krassimir Slavchev [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Most probably I missed something. I have problems with threads cleanup. Here are output of valgrind and simple test program: ... ==78317== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==78317== malloc/free: in use at exit: 4108 bytes in 2 blocks. ==78317== malloc/free: 5 allocs, 3 frees, 4324 bytes allocated. ==78317== ==78317== searching for pointers to 2 not-freed blocks. ==78317== checked 1468040 bytes. ==78317== ==78317== 12 bytes in 1 blocks are still reachable in loss record 1 of 2 ==78317==at 0x3C038183: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==78317==by 0x3C03F8D0: (within /usr/local/lib/valgrind/libthr.so.2) ==78317==by 0x3C040F49: pthread_mutex_init (in /usr/local/lib/valgrind/libthr.so.2) ==78317==by 0x3C040FA9: pthread_mutex_lock (in /usr/local/lib/valgrind/libthr.so.2) ==78317== ==78317== ==78317== 4096 bytes in 1 blocks are still reachable in loss record 2 of 2 ==78317==at 0x3C038183: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so) ==78317==by 0x3C121AE5: __smakebuf (in /lib/libc.so.6) ==78317==by 0x3C1219B0: __swsetup (in /lib/libc.so.6) ==78317==by 0x3C11789B: __vfprintf (in /lib/libc.so.6) ... You definitely need deeper stacktrace to see where mutexes are allocated. Info above says nothing otherwise. Also, note that when running threaded programs under valgrind you are testing valgrind's own threading library implementatiion, not 'real' libthr. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Bug in less version 406.
On Sat, 4 Aug 2007 01:29:57 +0200 Pieter de Goeje [EMAIL PROTECTED] wrote: There's also another regression in less: it doesn't automatically repaint the screen anymore when you resize the terminal. Regards, Pieter de Goeje It most certainly does here. -- Alexander Kabaev signature.asc Description: PGP signature
Re: ImageMagick's modules and __cxa_finalize
On Sun, 29 Jul 2007 23:31:10 -0400
Mikhail Teterin [EMAIL PROTECTED] wrote:
Has anyone had any luck using ImageMagick built with modules support?
If I try that, and follow-up with `gmake check' (in the ${WRKSRC}),
about a fifth of ImageMagick's own self-tests seg-fault -- all of
them inside __cxa_finalize (after main() has already returned):
[EMAIL PROTECTED]:ImageMagick/work/ImageMagick-6.3.5 (1023) gdb
tests/.libs/rwblob tests/rwblob.core [...]
(gdb) where 5
#0 0x000804008cc0 in ?? ()
#1 0x0008020079e2 in __cxa_finalize ()
from /lib/libc.so.6 #2 0x000802007637 in exit ()
from /lib/libc.so.6 #3 0x00401135 in _start ()
#4 0x00080052a000 in ?? ()
(More stack frames follow...)
(gdb)
[EMAIL PROTECTED]:ImageMagick/work/ImageMagick-6.3.5 (1024) gdb
tests/.libs/rwfile tests/rwfile.core [...]
(gdb) where 5
#0 0x000803f04cc0 in ?? ()
#1 0x0008020079e2 in __cxa_finalize ()
from /lib/libc.so.6 #2 0x000802007637 in exit ()
from /lib/libc.so.6 #3 0x00401085 in _start ()
#4 0x00080052a000 in ?? ()
(More stack frames follow...)
(gdb)
Full build/test log can be seen here:
http://aldan.algebra.com/~mi/IM-6.3.5-3.failure.log
Building without modules (as is the port's default) allows all
self-tests to pass smoothly.
According to ImageMagick and GraphicsMagick developers, these crashes
are due to some reckless calls to atexit() from inside the modules
(or inside the modules-loaded graphics librarires). By the time the
program is exiting, the libraries with the atexit-loaded functions
may already be unloaded.
But I thought, FreeBSD had that case covered since 2003:
http://www.freebsd.org/cgi/query-pr.cgi?pr=59552
Can someone, please, comment?
-mi
You thought wrong.
Please read the PR again and try to understand what part it really does
cover and what doesn't. The comment was given to you before and it is
the right one:
COMMENT
atexit() cannot be used safely from the shared library.
/COMMENT
That is the reason why __cxa_atexit was invented in the first place.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: OT: Re: Bug in 6.x' C++ compiler
On Thu, 12 Oct 2006 15:02:45 +0200 O. Hartmann [EMAIL PROTECTED] wrote: Well, I hope this bug has been sent by heaven and speeds up swapping system compiler of FreeBSD 6.X to 4.1 or 4.X :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] I've just had a confident message from heaven. They said major compiler upgrades in 6.x will not happen anytime soon and wanted me to pass this on to you. -- Alexander Kabaev signature.asc Description: PGP signature
Re: improper handling of dlpened's C++/atexit() code?
On Mon, 22 May 2006 06:50:55 +0300 Konstantin Belousov [EMAIL PROTECTED] wrote: On Sun, May 21, 2006 at 06:22:34PM -0400, m m wrote: n 5/21/06, Konstantin Belousov [EMAIL PROTECTED] wrote: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x294c0ad8 in __do_global_dtors_aux () from /usr/local/lib/perl5/5.8.8/mach/auto/Sys/Syslog/Syslog.so #2 0x294c1d4c in _fini () from /usr/local/lib/perl5/5.8.8/mach/auto/Sys/Syslog/Syslog.so #3 0x280b4c80 in ?? () #4 0x280aaab8 in ?? () from /libexec/ld-elf.so.1 #5 0xbfbfe6e8 in ?? () #6 0x2808dca6 in objlist_call_fini (list=0x280a96d8) at /usr/src/libexec/rtld-elf/rtld.c:1336 #7 0x2808e1d4 in rtld_exit () at /usr/src/libexec/rtld-elf/rtld.c:1528 #8 0x281d58ea in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:184 #9 0x281d55ba in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:69 #10 0x0805d0cb in clean_child_exit () #11 0x0805ea77 in just_die () #12 0x0805ea9a in usr1_handler () #13 0xbfbfffb4 in ?? () #14 0x001e in ?? () #15 0x in ?? () #16 0xbfbfe7c0 in ?? () #17 0x0002 in ?? () #18 0x0805ea80 in just_die () #19 0x0806011e in child_main () #20 0x080607de in make_child () #21 0x08060868 in startup_children () #22 0x08060e81 in standalone_main () #23 0x08061702 in main () Could you, please, put somewhere: 1. /usr/local/lib/perl5/5.8.8/mach/auto/Sys/Syslog/Syslog.so 2. output of lsof -p some apache child process pid for apache running in your usual configuration. Also, could you run the apache with LD_PRELOAD=/usr/lib/libstdc++.so.5 and report whether the problem persists ? Konstantin, Thank you for looking into this. lsof: http://www.savefile.com/files/6494253 Syslog.so: http://www.savefile.com/files/2163369 Although it's not an indicator of certainty (I have had it exit cleanly in the past), it appears that running Apache with LD_PRELOAD of libstdc++ does allow it to exit cleanly. Please let me know how I can further assist. If it would make things easier - I can provide access to a jail on this machine which exhibits the same behavior. Ok, I have a theory how it happens. Investigation of your instance of Syslog.so shows that crash happens at the following code of /usr/lib/crtbeginS.o: 282: if (__deregister_frame_info) 283: __deregister_frame_info (__EH_FRAME_BEGIN__); (this comes in from contrib/gcc/crtstuff.c, lines 282-283). Symbol __deregister_frame_info is weak and undefined in all your DSOs except libstdc++.so.5. This symbol provides part of the C++ runtime support for exception handling, and reasonably included from c++ runtime support library. Both lines 282 and 283 produce dynamic relocations in final DSO, but line 282 implies R_386_GLOB_DAT, and 283 - R386_JUMP_SLOT (for PLT). First relocation is resolved immediately on DSO load, second one is resolved on demand. My theory is that, at the time of loading Syslog.so, libstdc++.so.5 is loaded in the process, resulting in first relocation being satisfied by rtld immediately. But, at the time exit() processing comes to _fini() function of Syslog.so, libstdc++.so.5 is unloaded. And weak PLT relocation is resolved to 0. As result we got the frame #0 from your trace. This theory is confirmed by presence of libstdc++ in lsof output. Please, check that it does not show up at the time of crash dump by using show shared gdb command on crash dump. Short-time fix is to use LD_PRELOAD hack. The real solution would be to mark the libstdc++ DSO as unloadable and implement support for unloadable DSO in rtld (BTW, I think this is also needed for threading libraries libpthread and libthr for the same reason). I know that glibc dynamic loader has support for this feature. P.S. Apache seems to call exit(3) from the signal handler. This is wrong. Sounds very plausible to me. This should be fixed once we have shared libgcc_s.so. -- Alexander Kabaev signature.asc Description: PGP signature
Re: improper handling of dlpened's C++/atexit() code?
On Sun, 21 May 2006 13:13:35 -0400 m m [EMAIL PROTECTED] wrote: Any hints on this available? Suggestions, more info, anything else? On 5/15/06, m m [EMAIL PROTECTED] wrote: On 5/14/06, Alexander Kabaev [EMAIL PROTECTED] wrote: On Thu, 11 May 2006 20:57:20 -0400 m m [EMAIL PROTECTED] wrote: I am writing in regard to PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F59552 . I am experiencing behavior on 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #11: Sun Mar 26 00:03:52 EST 2006 which looks a lot like something that would be caused by this PR. This happens when apache-1.3 processes that run with Mason code receive a SIGUSR1 (when newsyslog does log rotation) and apache gracefully kills off all processes when restarting. The following is the stack trace that lead me to this PR: You'll need to build ld-elf.so.1 and libc.so.6 to get a sensible backtrace. Please find the new stack trace below. If there is more information I can provide, just ask. (This is 6.1-STABLE, cvsup very shortly before May 11 23:14 EDT) Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x294c0ad8 in __do_global_dtors_aux () from /usr/local/lib/perl5/5.8.8/mach/auto/Sys/Syslog/Syslog.so #2 0x294c1d4c in _fini () from /usr/local/lib/perl5/5.8.8/mach/auto/Sys/Syslog/Syslog.so #3 0x280b4c80 in ?? () #4 0x280aaab8 in ?? () from /libexec/ld-elf.so.1 #5 0xbfbfe6e8 in ?? () #6 0x2808dca6 in objlist_call_fini (list=0x280a96d8) at /usr/src/libexec/rtld-elf/rtld.c:1336 #7 0x2808e1d4 in rtld_exit () at /usr/src/libexec/rtld-elf/rtld.c:1528 #8 0x281d58ea in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:184 #9 0x281d55ba in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:69 #10 0x0805d0cb in clean_child_exit () #11 0x0805ea77 in just_die () #12 0x0805ea9a in usr1_handler () #13 0xbfbfffb4 in ?? () #14 0x001e in ?? () #15 0x in ?? () #16 0xbfbfe7c0 in ?? () #17 0x0002 in ?? () #18 0x0805ea80 in just_die () #19 0x0806011e in child_main () #20 0x080607de in make_child () #21 0x08060868 in startup_children () #22 0x08060e81 in standalone_main () #23 0x08061702 in main () Looks like normal atexit path to me. At this point a close look at Syslog.so is needed IMHO. I do not see anything criminal implicating FreeBSD in this crash in any way. -- Alexander Kabaev signature.asc Description: PGP signature
Re: improper handling of dlpened's C++/atexit() code?
On Thu, 11 May 2006 20:57:20 -0400 m m [EMAIL PROTECTED] wrote: I am writing in regard to PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=bin%2F59552 . I am experiencing behavior on 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #11: Sun Mar 26 00:03:52 EST 2006 which looks a lot like something that would be caused by this PR. This happens when apache-1.3 processes that run with Mason code receive a SIGUSR1 (when newsyslog does log rotation) and apache gracefully kills off all processes when restarting. The following is the stack trace that lead me to this PR: #0 0x in ?? () #1 0x2949dad8 in ?? () #2 0x294a02c4 in ?? () #3 0x281ca708 in ?? () from /lib/libc.so.6 #4 0xbfbfe708 in ?? () #5 0x28196556 in endhostent () from /lib/libc.so.6 #6 0x2949ed4c in ?? () #7 0x280a9980 in ?? () from /libexec/ld-elf.so.1 #8 0x280a9878 in ?? () from /libexec/ld-elf.so.1 #9 0xbfbfe718 in ?? () #10 0x2808d5ef in find_symdef () from /libexec/ld- elf.so.1 #11 0x2808da7c in find_symdef () from /libexec/ld-elf.so.1 #12 0x281ba09a in __cxa_finalize () from /lib/libc.so.6 #13 0x281b9d9a in exit () from /lib/libc.so.6 #14 0x0805cd5b in clean_child_exit (code=692716228) at http_main.c:522 #15 0x0805e707 in just_die (sig=30) at http_main.c:3202 #16 0x0805e72a in usr1_handler (sig=692716228) at http_main.c:3212 #17 0xbfbfffb4 in ?? () #18 0x001e in ?? () #19 0x in ?? () #20 0xbfbfe7e0 in ?? () #21 0x0002 in ?? () #22 0x0805e710 in just_die () at http_main.c:3202 #23 0x0805fdae in child_main (child_num_arg=692716228) at http_main.c:4571 #24 0x0806046e in make_child (s=0x294a02c4, slot=0, now=0) at http_main.c:5051 #25 0x080604f8 in startup_children (number_to_start=5) at http_main.c:5078 #26 0x08060b11 in standalone_main (argc=2, argv=0xbfbfeca0) at http_main.c:5410 #27 0x08061392 in main (argc=2, argv=0xbfbfeca0) at http_main.c:5767 Please let me know if you have any thoughts on the subject or if this is completely unrelated problem. Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] You'll need to build ld-elf.so.1 and libc.so.6 to get a sensible backtrace. -- Alexander Kabaev signature.asc Description: PGP signature
Re: ucom doesn't work in 6.1-PRERELEASE?
On Sat, 11 Mar 2006 17:46:24 +0100 Torfinn Ingolfsen [EMAIL PROTECTED] wrote: Hello, When I attatch my usb-to-serial based AVR programmer (an avrusb500) to a machine running FreeBSD 6.1-prerelease, it shows up in /var/log/messages as: Mar 11 17:25:03 kg-fil kernel: ucom0: FTDI USB - Serial, rev 1.10/4.00, addr 2 However, there is no /dev/ucom0 entry. Details: [EMAIL PROTECTED] uname -a FreeBSD kg-fil.kg4.no 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #5: Sat Mar 11 15:05:47 CET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIL60 amd64 [EMAIL PROTECTED] kldstat Id Refs AddressSize Name 19 0x8010 8b6820 kernel 21 0x809b7000 67e0 snd_ich.ko 32 0x809be000 346a8sound.ko 41 0xa7c19000 1cd blank_saver.ko 51 0xa7cb 10b6 uftdi.ko 61 0xa7cb2000 112f ucom.ko (as you can see, both utfdi and ucom is loaded). [EMAIL PROTECTED] usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x), nVidia(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 addr 2: full speed, power 90 mA, config 1, USB - Serial(0x6001), FTDI(0x0403), rev 4.00 port 5 powered port 6 powered port 7 powered port 8 powered port 9 powered port 10 powered But, no /dev/ucom* : [EMAIL PROTECTED] ls -l /dev/ucom* ls: /dev/ucom*: No such file or directory [EMAIL PROTECTED] ls -l /dev/usb* crw-rw 1 root operator0, 30 Mar 11 15:50 /dev/usb crw-rw 1 root operator0, 29 Mar 11 15:50 /dev/usb0 crw-rw 1 root operator0, 31 Mar 11 15:50 /dev/usb1 even if the usb entries are there. [EMAIL PROTECTED] ps ax | grep usbd 405 ?? Is 0:00.00 /usr/sbin/usbd For comparison, the device works fine under 5.4-stable: [EMAIL PROTECTED] uname -a FreeBSD kg-work.kg4.no 5.4-STABLE FreeBSD 5.4-STABLE #5: Sat Dec 31 16:54:14 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SS51G i386 Mar 11 17:44:17 kg-work kernel: ucom0: FTDI USB - Serial, rev 1.10/4.00, addr 2 [EMAIL PROTECTED] ls -l /dev/ucom* crw-rw 1 uucp dialer 220, 128 Jan 4 17:10 /dev/ucom0 [EMAIL PROTECTED] ls -l /dev/usb* crw-rw 1 root operator 239, 255 Jan 4 17:10 /dev/usb crw-rw 1 root operator 239, 0 Jan 4 17:10 /dev/usb0 crw-rw 1 root operator 239, 1 Jan 4 17:10 /dev/usb1 crw-rw 1 root operator 239, 2 Jan 4 17:10 /dev/usb2 crw-rw 1 root operator 239, 3 Jan 4 17:10 /dev/usb3 What's wrong, and how do I fix it? -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] /dev/ucomX devices became /dev/ttyUX devices quite some time ago. -- Alexander Kabaev signature.asc Description: PGP signature
