nl_langinfo problem
It seems that I am addressing a FreeBSD problem after a Perl installation and a rebuild of the shared lib files Now some perl programs don't work and some apparently non-perl programs have suferred the same faith as well. Its a bit confusing and help is needed !! ___ Sys Specs: FreeBSD kooler.com 4.9-STABLE FreeBSD 4.9-STABLE #0: Wed Nov 12 17:41:01 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STANDARD i386 ___ Under Perl 5.8.2 installed an API and rebuilt shared lib hint files ,/var/run/ld.so.hints /var/run/ld-elf.so.hints, w/ ldconfig -aout, ldconfig -elf, followed by ldconfig -m library directory after experiencing difficulties sourcing some essential *.so files. After this persistent nl_langinfo problem created. Ex: launching Perl at the command line == /usr/libexec/ld-elf.so.1: /usr/local/lib/perl5/5.8.2/mach/CORE/libperl.so: Undefined symbol nl_langinfo Decided to rebuild upgrade perl w/ V-5.8.8, but this is producing similar problems even at ./configure stage== *** Error code 1 (ignored) ./miniperl -Ilib configpm --heavy=lib/Config_heavy.pl lib/Config.pm /usr/libexec/ld-elf.so.1: ./miniperl: Undefined symbol nl_langinfo *** Error code 1 Stop in /usr/home/koolsrc/perl/perl-5.8.8. Running /etc/periodic/daily/430.status-rwho Local system status: /usr/libexec/ld-elf.so.1: uptime: Undefined symbol nl_langinfo man -k ls /usr/libexec/ld-elf.so.1: man: Undefined symbol nl_langinfo ___ _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adm1026 support
Hi, Can you tell me on which Release of BSD (5.5 or pre 5.5) have the support for ADM1026 Driver? Thanks, YTR -- View this message in context: http://www.nabble.com/adm1026-support-tf1800838.html#a5078824 Sent from the freebsd-hackers forum at Nabble.com. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adm1026 support
YTR writes: Can you tell me on which Release of BSD (5.5 or pre 5.5) have the support for ADM1026 Driver? It isn't supported, but see this: http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016886.html --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
wine: mapping memory problems
hi, all.
in wine project there are few problems on freebsd with windows 16-bits
programs.
when you'll run such program, wine will crashed with stack overflow.
in fact, on freebsd wine doesn't map 1st megabyte of virtual memory,
but it should.
see ./libs/wine/mmap.c ./dlls/winedos/dosmem.c ./libs/wine/ldt.c
in dosmem.c DOSMEM_system should has mapped address, but programs
crashes on memset:
static void DOSMEM_FillBiosSegments(void)
{
BYTE *pBiosSys = (BYTE*)DOSMEM_dosmem + 0xf;
BYTE *pBiosROMTable = pBiosSys+0xe6f5;
BIOSDATA *pBiosData = DOSVM_BiosData(); /* in this case *pBiosData
= (BIOSDATA *)(DOSMEM_sysmem + 0x400);*/
static const char bios_date[] = 13/01/99;
/* Clear all unused values */
memset( pBiosData, 0, sizeof(*pBiosData) ); /* !!crashes here!! */
/* ... */
have you any suggestions how to resolve this problem?
beforehand 10x for help.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [fbsd] Source ScreenSaver
Hi, It follows link of the code and the procedures http://200.193.29.195/saver/index.html I have just given a try to it and I must admit it is very, very good looking. I even prefer it to the non-OpenGL matrix module from xscreensaver. Is it possible to added it to the source tree, or are the syscons screensavers doomed to die soon (which would therefore prevent from adding a new screensaver) ? Thank you for your work. I am not sure it will help FreeBSD being better on the server market, but it surely makes it nicer. I think this feature stands beside the colored rc.conf(5) patch. Best regards, -- Jeremie Le Hen jeremie at le-hen dot org ttz at chchile dot org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Return value of malloc(0)
There is a nice extension for firefox called prefbar. However, newer versions of prefbar (=3.3) make firefox die with SIGSEGV, see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details. The crash happens in libgklayout.so: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100116)] 0x29a9599b in nsGlobalWindow::RunTimeout (this=0x8393500, aTimeout=0x8935000) at nsGlobalWindow.cpp:6378 6378 timeout-mArgv[timeout-mArgc] = Current language: auto; currently c++ (gdb) p timeout-mArgc $1 = 0 (gdb) p timeout-mArgv $2 = (jsval *) 0x800 (gdb) p timeout-mArgv[timeout-mArgc] Error accessing memory address 0x800: Bad address. The 0x800 are the result of an earlier malloc(0). When looking at the MALLOC(3) manpage, we can read (near the description of the flags): ... VAttempting to allocate zero bytes will return a NULL pointer instead of a valid pointer. (The default behavior is to make a minimal allocation and return a pointer to it.) This option is provided for System V compatibility. This option is incompatible with the ``X'' option. ... So I gave it a try by running MALLOC_OPTIONS=V firefox and firefox didn't crash anymore and prefbar was running :-). (Now malloc returns NULL and firefox doesn't interpret the result as a pointer to some allocated memory and therefore doesn't use it). The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. I assume the behaviour is meant to show up programming errors: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. Opinions, please... -Andre P.S.: If someone wants to know where the crash happens in firefox please see http://bugzilla.mozdev.org/show_bug.cgi?id=13809. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: nl_langinfo problem
Problem Solved perl-freebsd, Anton Berezin _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Andre Albsmeier [EMAIL PROTECTED] writes: The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. The C standard explicitly allows both behaviours, and requires the implementation to choose one of them. If it returns a non-NULL pointer, though, that pointer can *only* be used for passing back to free(). It may *not* be dereferenced. So firefox is wrong, and actually broken. I assume the behaviour is meant to show up programming errors: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). Yes. In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). I don't see what you are claiming is wrong. Can you give a brief description of you're suggesting. Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. That would be reasonable, particularly for the time being. However, the firefox bug really should be fixed in the upstream sources. Writing past the end of an allocated buffer (which is what the code does, if you think about it) is a serious error. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. The C language standard agrees with this position... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: There is a nice extension for firefox called prefbar. However, newer versions of prefbar (=3.3) make firefox die with SIGSEGV, see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details. The crash happens in libgklayout.so: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100116)] 0x29a9599b in nsGlobalWindow::RunTimeout (this=0x8393500, aTimeout=0x8935000) at nsGlobalWindow.cpp:6378 6378 timeout-mArgv[timeout-mArgc] = Current language: auto; currently c++ (gdb) p timeout-mArgc $1 = 0 (gdb) p timeout-mArgv $2 = (jsval *) 0x800 (gdb) p timeout-mArgv[timeout-mArgc] Error accessing memory address 0x800: Bad address. The 0x800 are the result of an earlier malloc(0). When looking at the MALLOC(3) manpage, we can read (near the description of the flags): ... VAttempting to allocate zero bytes will return a NULL pointer instead of a valid pointer. (The default behavior is to make a minimal allocation and return a pointer to it.) This option is provided for System V compatibility. This option is incompatible with the ``X'' option. ... So I gave it a try by running MALLOC_OPTIONS=V firefox and firefox didn't crash anymore and prefbar was running :-). (Now malloc returns NULL and firefox doesn't interpret the result as a pointer to some allocated memory and therefore doesn't use it). The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. I assume the behaviour is meant to show up programming errors: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. Opinions, please... The C Standard says the following about malloc(0): If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. So our default behaviour to crash if a pointer returned by malloc(0) is dereferenced is legal and a good one because it catches errors like the above one. I agree that the wording in the man page should be improved. Probably it should say that malloc(0) returns a non-NULL pointer which must not be dereferenced without mentioning a minimal allocation. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: (Now malloc returns NULL and firefox doesn't interpret the result as a pointer to some allocated memory and therefore doesn't use it). Return NULL for malloc(0) is one of two possible implementations. The other behaviour is to generate a unique pointer for each call. Both behaviours are intentionally allowed by the standard and code making assumptions about either is broken. It should be added that returning NULL for malloc(0) is consistent with realloc, so it is actually nicer. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sysctl network stats
Hi, I'm doing a piece of software in perl to collect system stats. Now I'm working on network i/o stats, and I want to collect the per interface informations. I just looking for some informations about datas I can collect thought the sysctl call. regards - ros ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Hi All, I'm trying to port my compiler from Linux to freeBSD. It looked like a simple job up to the point I ran my flex code through FLEX on freeBSD. When GCC processes lex.yy.c I get a complaint about an illegal numeric constant in yy_get_next_buffer, which is all FLEX generated (or prewritten) code. The thing compiler just fine under Linux. Any ideas? Cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Wed, Jun 28, 2006 at 06:41:05PM -0700, Randall Hyde wrote: Hi All, I'm trying to port my compiler from Linux to freeBSD. It looked like a simple job up to the point I ran my flex code through FLEX on freeBSD. When GCC processes lex.yy.c I get a complaint about an illegal numeric constant in yy_get_next_buffer, which is all FLEX generated (or prewritten) code. The thing compiler just fine under Linux. Any ideas? Cheers, Randy Hyde Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
- Original Message - From: Steve Kargl [EMAIL PROTECTED] To: Randall Hyde [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org Sent: Wednesday, June 28, 2006 10:10 PM Subject: Re: Return value of malloc(0) On Wed, Jun 28, 2006 at 06:41:05PM -0700, Randall Hyde wrote: Hi All, I'm trying to port my compiler from Linux to freeBSD. It looked like a simple job up to the point I ran my flex code through FLEX on freeBSD. When GCC processes lex.yy.c I get a complaint about an illegal numeric constant in yy_get_next_buffer, which is all FLEX generated (or prewritten) code. The thing compiler just fine under Linux. Any ideas? Cheers, Randy Hyde Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. A new thread with a proper subject would be appropriate too :) -- Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FLEX, was Re: Return value of malloc(0)
Without seeing the code or the actual error message, I'm guessing the answer is 42. Perhaps, some detail might be appropriate. I seriously doubt seeing the code will do much good. Here's the offending line: YY_INPUT( (yy_current_buffer-yy_ch_buf[number_to_move]), yy_n_chars, num_to_read ); This is from static int yy_get_next_buffer() Which is part of the canned code that comes with FLEX. Compiles just fine under Linux. Linux has a slightly newer version of GCC, but I've been compiling this code on Windows (Borland and VC++) as well as Linux for years without a problem (i.e., older versions of GCC). BTW, if anyone is intrested in the full FLEX source, it's part of the HLA (High Level Assembler) source package found here: http://webster.cs.ucr.edu/AsmTools/HLA/HLAv1.84/hlasrc.zip I compiled the FLEX code with the command line: flex -8 -i hla.flx This works fine, then I compile the GCC output with gcc -DfreeBSD -c -o lex.yy.o lex.yy.c and it stops with syntax error before numeric constant. As this code is in part of the FLEX-supplied C code, I would think that this problem would be independent of my particular flex code. BTW, I've tried using both the FLEX I use on Linux under BSD as well as the BSD-supplied version. I've even taken the FLEX output from freeBSD and compiled it under Linux (it compiles successfully. I'm using GCC 3.3.5 under Linux, 3.4.4 under BSD. Any known problems with 3.4.4 that would cause this? cheers, Randy Hyde ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
Hi, On Wed, Jun 28, 2006 at 08:10:45PM +0200, Andre Albsmeier wrote: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). They should check the return value of malloc() in any case for successful allocation.. shouldn't they? -- Quits: JESUS ([EMAIL PROTECTED]): Ping timeout Cyph3r jesus died from my syn's ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
