I use backtrace() and backtrace_symbols() to get some information.
outputs looks like:
./a.out
....
(_Z8fun+0x1d( [0x400bb3]
/lib64/libpthread.so.0 (+0x7dc5) [**0x7f2cb2b99dc5**]
/lib64/libc.so.6(clone+0x6d) [**0x7fc20a61cd**]
...
In redhat 7, the bolder addrs is always change between times,
while in redhat 6, the addrs looks fixed.
In redhat 7, the bolder addrs is always change between times, while in redhat 6, the addrs looks fixed
The addresses change because most modern systems use Address Space Layout Randomization to make certain class of exploits harder.
ASLR was introduced into the Linux kernel in 2001, and redhat-6.2 release predates this.
P.S. Using such an old distribution for anything is ill-advised: you are missing 16 years worth of security and performance improvements.
Related
The laptop is ASUS FX503vd, I tried several versions of Linux kernels (currently running one is the 4.17.1), but still have not managed to make the keyboard backlight control keys work. After the system boot on, the backlight is always on. There are two function keys (reused the numerical keypad) which is to control the brightness of the backlight. In windows, I can adjust down its brightness until fully off. But pressing the same keys in Linux has no effect at all. My feeling is the kernel did not detected the corresponding WMI device
Below is the /sys/devices/platform/asus-nb-wmi/ contents:
~ $ ls /sys/devices/platform/asus-nb-wmi/
cpufv driver_override input/ power/ uevent
driver# hwmon/ modalias subsystem#
And, below is the kernel message filtered by 'asus' keyword: (i.e. dmesg |grep 'asus')
[ 6.698065] asus_wmi: ASUS WMI generic driver loaded
[ 6.700669] asus_wmi: Initialization: 0x1
[ 6.700723] asus_wmi: BIOS WMI version: 8.1
[ 6.700764] asus_wmi: SFUN value: 0x4a0061
[ 6.701323] input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input10
[ 6.703080] asus_wmi: Number of fans: 1
Does anyone have some clues about the laptop keyboard issue?
Does the driver depend on the layout of the keyboard?
Thanks in advance.
-woody
Here is guid in kernel Documentation in Documentation/laptops/asus-laptop.txt.
According to that follow the steps to enable this functionality.
modprobe asus-laptop (check dmesg)
You can control lcd backlight power and brightness with
/sys/class/backlight/asus-laptop/. Brightness Values are between 0 and 15.
I hope you did it somehow but for those who didn't managed to do it, there is a little advice
!!! This works only on ubuntu based distros !!!
You will probably have to install newer kernel (which is not in repository for everyone to install). That may help you with much more problems like backlight issues or so.
You can look at this answer. There is written how to update your current kernel. kernel versions are not up to date so you'll have to choose some higher version.
I hope this helps :)
I wonder because running it on a client's minidump it reports a different Windows version than the client repeatedly told me she had, and the version I'm being reported happens to be exactly the same version I'm running WinDbg on.
So I wonder, can vertarget always be trusted (and clients not) or the information it relies on may be absent with some dump generation options and when it is it reports the version WinDbg is currently running on, or maybe just some default that happens to coincide with my OS version?
I'm using WinDbg 6.12.
In all my cases so far, vertarget has been correct and the customer/client made a mistake - and vertarget is one of the commands I use for every dump, exactly for the purpose of checking if the dump contains what I need.
But perhaps, things can potentially go wrong here as well, so let's evaluate some options:
vertarget also reports debug session time and system uptime. Do those also match your system? Reboot your system in order to get a low system uptime and check again. Is it still your PC's uptime?
vertarget also reports the number of CPUs. Does that number match your number?
Get a virtual machine which does not have your OS, e.g. one from Modern.IE (Microsoft). Copy WinDbg and the dump to the VM and check the output of vertarget again.
WinDbg 6.12 is a bit old. Do newer versions (6.2.9200 / 6.3.9600 or even 10.0) provide the same information or was there a bug fixed already?
And even check some other information:
Is it a dump of the correct application? Use | (pipe)
Is it a dump of the version you are expecting? Use lm vm <exename>
Does it have the flags which can be expected for the method used for taking the dump? Use .dumpdebug.
Other than that I observe (not representative) that many client OS version dumps (Windows 7, 8, 8.1) have all latest service packs installed, while administrators seem to follow the "never change a running system" approach for server OS (Windows Server 2012, R2). So it might just be a coincident.
I have a fc14 32 bit system with 2.6.35.13 custom compiled kernel.
When I try to start G-wan I get a "Segmentation fault".I've made no changes, just downloaded and unpacked the files from g-wan site.
In the log file I have:
"[Wed Dec 26 16:39:04 2012 GMT] Available network interfaces (16)"
which is not true, on the machine i have around 1k interfaces mostly ppp interfaces.
I think the crash has something to do with detecting interfaces/ip addresses because in the log after the above line I have 16 lines with ip's belonging to the fc14 machine and after that about 1k lines with "0.0.0.0" or "random" ip addresses.
I ran gwan 3.3.7 64-bit on a fc16 with about the same number of interfaces and had no problem,well it still reported a wrong number of interfaces (16) but it did not crashed and in the log file i got only 16 lines with the ip addresses belonging to the fc16 machine.
Any ideas?
Thanks
I have around 1k interfaces mostly ppp interfaces
Only the first 16 will be listed as this information becomes irrelevant with more interfaces (the intent was to let users find why a listen attempt failed).
This is probably the long 1K list, many things have changed internally after the allocator was redesigned from scratch. Thank you for reporting the bug.
I also confirm the comment which says that the maintenance script crashes. Thanks for that.
Note that bandwidth shaping will be modified to avoid the newer Linux syscalls so the GLIBC 2.7 requirement will be waved.
...with a custom compiled kernel
As a general rule, check again on a standard system like Debian 6.x before asking a question: there is room enough for trouble with a known system - there's no need to add custom system components.
Thank you all for the tons(!) of emails received these two last days about the new release!
I had a similar "Segmentation fault" error; mine happens any time I go to 9+GB of RAM. Exact same machine at 8GB works fine, and 10GB doesn't even report an error, it just returns to the prompt.
Interesting behavior... Have you tried adjusting the amount of RAM to see what happens?
(running G-WAN 4.1.25 on Debian 6.x)
In the OpGuide on page 61:
SERVER_PRIORITY_CLASS . Priority of the InterBase service on Windows server
platforms
. The value 1 is low priority, 2 is high priority
. Relevant only on Windows server platforms
. Default is 1
In the IBConfig file distributed with Interbase:
#SERVER_PRIORITY_CLASS 1
## Platforms: Windows
## Priority of the InterBase service on Windows
## The value 1 is low priority, 2 is high priority.
## Relevant only on Windows NT/2000/XP.
Just need a clarification when it is appropriate to change the
Server_Priority_Class from the default (1) to 2.
The comment in the IBConfig file makes it sound that the setting is only for
Windows NT/2000/XP, where the OpGuide says it is relevant only on Windows
server platforms. None of our servers use Windows NT/2000/WinXP (all are Window Server 2003, 2008, etc)
Thanks,
Tom Greenway
It does have an effect on any Windows version. The language in the comment stems from the days when IB was still supported on Windows 95.
However, you usually should not change this. Let the OS set thread priority.
This error according to the logs is caused by a 5-year old Perl script that merely grabs data from MySQL via a simple SQL select and displays it.
It's running on my dev machine which is MBP with 8GB of RAM running the stock Apache.
Once a while, once or twice a month, I get the following error for no apparent reason :
panic: memory wrap at /System/Library/Perl/5.10.0/CGI.pm line 4001.
Apache refuses to run the script again and only a reboot of the OS would make Apache relent. The OS says that there's 3+ GB of free memory when it happens so it's not a low memory issue. Luckily this doesn't happen on the production Debian 5 server.
What's a memory wrap? And what causes it?
I hit this bug as well in a slightly different circumstance. PerlMonks, as ever, has just saved me probably days of work:
http://www.perlmonks.org/?node_id=823389
the problem lies in the way osx ties
up other resources. a simple sleep
will give the os time to close and
open. restart or graceful will go in
conflict.
apachectl stop
sleep 2
apachectl start
This is late but the perl distributed by MacPorts does not have this problem, if that is an option.
mu is too short's answer, which as unfortunately posted as a comment. :
perldiag says that "panic: memory wrap" means "Something tried to allocate more memory than possible". A bit of googling suggests that this isn't a CGI.pm problem but an occassional problem with Perl 5.10 and OSX.