gdb /usr/sbin/httpd ./core
(gdb) bt
#0 0x00002af748ff9265 in ?? ()
#1 0x00002af748ffad10 in ?? ()
#2 0x00007fff0a31e248 in ?? ()
#3 0x00007fff0a317aa0 in ?? ()
#4 0x00007fff0a317a10 in ?? ()
#5 0x00007fff0a317ad0 in ?? ()
#6 0x0000000200000000 in ?? ()
plase tell me how to.
thank u.
Your core file comes from an executable built without debugging information. That is why the display of your execution stack lacks function names and lines information
#0 0x00002af748ff9265 in ?? ()
The most likely reason you don't get any symbol names in the core dump is that you either
Have a truncated core, or
Are analyzing core that was produced on a different system from the one you are running GDB on, or
Have a stripped executable (in which case, nm /usr/sbin/httpd will say stripped or something).
My bet it's 1 or 2. If it is 2, see this answer. If it is 3, and you are using system-provided apache build, see if installing httpd-debug or similar package helps.
Related
I'm running some code under Valgrind, compiled with gcc 7.5 targeting an aarch64 (ARM 64 bits) architecture, with optimizations enabled.
I get the following error:
==3580== Invalid write of size 8
==3580== at 0x38865C: ??? (in ...)
==3580== Address 0x1ffeffdb70 is on thread 1's stack
==3580== 16 bytes below stack pointer
This is the assembly dump in the vicinity of the offending code:
388640: a9bd7bfd stp x29, x30, [sp, #-48]!
388644: f9000bfc str x28, [sp, #16]
388648: a9024ff4 stp x20, x19, [sp, #32]
38864c: 910003fd mov x29, sp
388650: d1400bff sub sp, sp, #0x2, lsl #12
388654: 90fff3f4 adrp x20, 204000 <_IO_stdin_used-0x4f0>
388658: 3dc2a280 ldr q0, [x20, #2688]
38865c: 3c9f0fe0 str q0, [sp, #-16]!
I'm trying to ascertain whether this is a possible bug in my code (note that I've thoroughly reviewed my code and I'm fairly confident it's correct), or whether Valgrind will blindly report any writes below the stack pointer as an error.
Assuming the latter, it looks like a Valgrind bug since the offending instruction at 0x38865c uses the pre-decrement addressing mode, so it's not actually writing below the stack pointer.
Furthermore, at address 0x388640 a similar access (and again with pre-decrement addressing mode) is performed, yet this isn't reported by Valgrind; the main difference being the use of an x register at address 0x388640 versus a q register at address 38865c.
I'd also like to draw attention to the large stack pointer subtraction at 0x388650, which may or may not have anything to do with the issue (note this subtraction makes sense, given that the offending C code declares a large array on the stack).
So, will anyone help me make sense of this, and whether I should worry about my code?
The code looks fine, and the write is certainly not below the stack pointer. The message seems to be a valgrind bug, possibly #432552, which is marked as fixed. OP confirms that the message is not produced after upgrading valgrind to 3.17.0.
code declares a large array on the stack
should [I] worry about my code?
I think it depends upon your desire for your code to be more portable.
Take this bit of code that I believe represents at least one important thing you mentioned in your post:
#include <stdio.h>
#include <stdlib.h>
long long foo (long long sz, long long v) {
long long arr[sz]; // allocating a variable on the stack
arr[sz-1] = v;
return arr[sz-1];
}
int main (int argc, char *argv[]) {
long long n = atoll(argv[1]);
long long v = foo(n, n);
printf("v = %lld\n", v);
}
$ uname -mprsv
Darwin 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64 i386
$ gcc test.c
$ a.out 1047934
v = 1047934
$ a.out 1047935
Segmentation fault: 11
$ uname -snrvmp
Linux localhost.localdomain 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64
$ gcc test.c
$ ./a.out 2147483647
v = 2147483647
$ ./a.out 2147483648
v = 2147483648
There are at least some minor portability concerns with this code. The amount of allocatable stack memory for these two environments differs significantly. And that's only for two platforms. Haven't tried it on my Windows 10 vm but I don't think I need to because I got bit by this one a long time ago.
Beyond OP issue that was due to a Valgrind bug, the title of this question is bound to attract more people (like me) who are getting "invalid write at X bytes below stack pointer" as a legitimate error.
My piece of advice: check that the address you're writing to is not a local variable of another function (not present in the call stack)!
I stumbled upon this issue while attempting to write into the address returned by yyget_lloc(yyscanner) while outside of function yyparse (the former returns the address of a local variable in the latter).
When I go to a simple product in order to adjust the price I get a error when I save the product.
Error
There has been an error processing your request
Decoding failed: Syntax error
Trace:
#0 /data/web/public/app/code/core/Mage/Core/Helper/Data.php(659): Zend_Json::decode('', 1)
#1 /data/web/public/app/code/local/Amasty/Conf/Model/Observer.php(145): Mage_Core_Helper_Data->jsonDecode(NULL)
#2 /data/web/public/app/code/core/Mage/Core/Model/App.php(1357): Amasty_Conf_Model_Observer->onSuperProductAttributesPrepareSave(Object(Varien_Event_Observer))
#3 /data/web/public/app/code/core/Mage/Core/Model/App.php(1336): Mage_Core_Model_App->_callObserverMethod(Object(Amasty_Conf_Model_Observer), 'onSuperProductA...', Object(Varien_Event_Observer))
#4 /data/web/public/app/Mage.php(448): Mage_Core_Model_App->dispatchEvent('catalog_product...', Array)
#5 /data/web/public/app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php(670): Mage::dispatchEvent('catalog_product...', Array)
#6 /data/web/public/app/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.php(725): Mage_Adminhtml_Catalog_ProductController->_initProductSave()
#7 /data/web/public/app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Adminhtml_Catalog_ProductController->saveAction()
#8 /data/web/public/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('save')
#9 /data/web/public/app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#10 /data/web/public/app/code/core/Mage/Core/Model/App.php(365): Mage_Core_Controller_Varien_Front->dispatch()
#11 /data/web/public/app/Mage.php(683): Mage_Core_Model_App->run(Array)
#12 /data/web/public/index.php(83): Mage::run('dutch', 'store')
#13 {main}
Error log record number: 817468762686
I hope someone can tell me what may be the cause.
Best regards,
Michel
Might you be running Magento 1.9 on a PHP7 System? This answer only applies if you are running PHP7. If so, try PHP5.6 and see if it still gives you a problem.
If you are on PHP7, it may be because you need the Inchoo_PHP7 Extension.
Have a look here: https://community.magento.com/t5/Technical-Issues/Magento-1-9-2-create-account-cannot-save-the-customer-error/m-p/42237#M3899
And also here on GitHub, where the extension can also be downloaded: github.com/Inchoo/Inchoo_PHP7/issues/29
I myself had a similar issue on new order creation at http://www.buildersdepot.com, but it seems connected to PHP7, so updating with a new Incho_PHP7 download seems to have done the trick for me on 8/6/2016, my old version was dated around 4/1/2016.
I have followed this step by step instruction to create a table in my database using migrate command but I wondered how it is finalized at the last step. after running "yiic migrate" command I get the following message:
Yii Migration Tool v1.0 (based on Yii v1.1.13)
exception 'CDbException' with message 'CDbConnection.connectionString cannot be
empty.' in D:\wamp\www\news\framework\db\CDbConnection.php:369
Stack trace:
#0 D:\wamp\www\news\framework\db\CDbConnection.php(330): CDbConnection->open()
#1 D:\wamp\www\news\framework\db\CDbConnection.php(308): CDbConnection->setActiv
e(true)
#2 D:\wamp\www\news\framework\base\CModule.php(387): CDbConnection->init()
#3 D:\wamp\www\news\framework\cli\commands\MigrateCommand.php(442): CModule->get
Component('db')
#4 D:\wamp\www\news\framework\cli\commands\MigrateCommand.php(451): MigrateComma
nd->getDbConnection()
#5 D:\wamp\www\news\framework\cli\commands\MigrateCommand.php(482): MigrateComma
nd->getMigrationHistory(-1)
#6 D:\wamp\www\news\framework\cli\commands\MigrateCommand.php(84): MigrateComman
d->getNewMigrations()
#7 [internal function]: MigrateCommand->actionUp(Array)
#8 D:\wamp\www\news\framework\console\CConsoleCommand.php(172): ReflectionMethod
->invokeArgs(Object(MigrateCommand), Array)
#9 D:\wamp\www\news\framework\console\CConsoleCommandRunner.php(67): CConsoleCom
mand->run(Array)
#10 D:\wamp\www\news\framework\console\CConsoleApplication.php(91): CConsoleComm
andRunner->run(Array)
#11 D:\wamp\www\news\framework\base\CApplication.php(169): CConsoleApplication->
processRequest()
#12 D:\wamp\www\news\framework\yiic.php(33): CApplication->run()
#13 D:\wamp\www\news\framework\yiic(14): require_once('D:\wamp\www\new...')
#14 {main}
I don't know what command I have to run after it and how to finish up with the migration process!
Does anybody have a solution on this issue? (I am also using windows 7)
Inside config/console.php add database configuration
'components' => array(
'db'=> array(
'connectionString' => '',
'username' => '',
'password' => '',
)
)
with appropriate database details
You seem to miss the db configuration block in your config/console.php.
I'm using Redis (2.4.2) and with the INFO command I can read stats about my Redis server.
There are many stats, including some about how much memory is used. And one is "used_memory_peak" that seems to hold the maximum amount of memory Redis has ever taken.
I've deleted a bunch of key, and I'd like to reset this stat since it affects the scale of my Munin graphs.
There is a CONFIG RESETSTAT command, but it doesn't seem to affect this particular stat.
Any idea how I could do this, without having to export/delete/import my dataset ?
EDIT :
According to #antirez himself (issue 369 on GitHub), this is an intended behavior, but it this feature could be improved to be more useful in a future release.
The implementation of CONFIG RESETSTAT is quite simple:
} else if (!strcasecmp(c->argv[1]->ptr,"resetstat")) {
if (c->argc != 2) goto badarity;
server.stat_keyspace_hits = 0;
server.stat_keyspace_misses = 0;
server.stat_numcommands = 0;
server.stat_numconnections = 0;
server.stat_expiredkeys = 0;
addReply(c,shared.ok);
So it does not initialize the server.stat_peak_memory field used to store the maximum amount of memory ever used by Redis. I don't know if it is a bug or a feature.
Here is a hack to reset the value without having to stop Redis. The idea is to use gdb in batch mode to just change the value of the variable (which is part of a static structure). Normally Redis is compiled with debugging symbols.
# Here we have plenty of things in this instance
> ./redis-cli info | grep peak
used_memory_peak:1363052184
used_memory_peak_human:1.27G
# Let's do some cleaning: everything is wiped out
# don't do this in production !!!
> ./redis-cli flushdb
OK
# Again the same values, while some memory has been freed
> ./redis-cli info | grep peak
used_memory_peak:1363052184
used_memory_peak_human:1.27G
# Here is the magic command: reset the parameter with gdb (output and warnings to be ignored)
> gdb -batch -n -ex 'set variable server.stat_peak_memory = 0' ./redis-server `pidof redis-server`
Missing separate debuginfo for /lib64/libm.so.6
Missing separate debuginfo for /lib64/libdl.so.2
Missing separate debuginfo for /lib64/libpthread.so.0
[Thread debugging using libthread_db enabled]
[New Thread 0x41001940 (LWP 22837)]
[New Thread 0x40800940 (LWP 22836)]
Missing separate debuginfo for /lib64/libc.so.6
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff51ff000
0x00002af0b5eef218 in epoll_wait () from /lib64/libc.so.6
# And now, result is different: great !
> ./redis-cli info | grep peak
used_memory_peak:718768
used_memory_peak_human:701.92K
This is a hack: think twice before applying this trick on a production instance.
Simple trick to clear peal memory::
Step 1:
/home/logproc/redis/bin/redis-cli BGREWRITEAOF
wait till it finish rewriting aof file.
Step 2:
restart redis db
Done. Thats It.
I have to debug a Cocoa/Objective-C app that has had its symbols stripped. I am pretty well versed in gdb and Objective-C. Normally, I use tools like otool or class-dump to find out what I need to make debugging a little easier. For example, class-dump makes it easy to know where, at runtime, certain methods live.
My question is: Can I "help" gdb provide better symbolic information at runtime when looking at backtraces? In the following backtrace I know (from using class-dump) what all of the methods marked as "??" are. It would be great if I could get gdb to do this for me.
Thanks!
(gdb) bt
#0 0x960de54e in -[NSPersistentUIManager init] ()
#1 0x960de489 in __PersistentUIManager_block_invoke_1 ()
#2 0x9abd0693 in _NSFaultInObject ()
#3 0x960ad800 in +[NSPersistentUIManager sharedManager] ()
#4 0x961aefac in -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] ()
#5 0x961aeefd in -[NSWindow orderWindow:relativeTo:] ()
#6 0x96238acc in -[NSWindow orderFront:] ()
#7 0x0000a032 in ?? ()
#8 0x9154bdaa in -[NSObject performSelector:] ()
#9 0x9154bd27 in -[NSSet makeObjectsPerformSelector:] ()
#10 0x960c16a7 in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] ()
#11 0x960b744d in loadNib ()
#12 0x960b6834 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] ()
#13 0x960b673e in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] ()
#14 0x960b6672 in +[NSBundle(NSNibLoading) loadNibNamed:owner:] ()
#15 0x9633d6c7 in NSApplicationMain ()
#16 0x00002cc6 in ?? ()
#17 0x00002bed in ?? ()
You would need the symbol tables that were generated at the time of the build; typically, the .dSYM folder(s). With those, you can add-symbol-table in GDB and it'll generally figure things out a bit more.
You can't really produce the symbol tables after the fact. Many developers will archive off a copy of the symbol tables for various production releases of their app such that crash traces can be symbolicated and reproducible crashes (that only reproduce on production builds or a particular client install) can be debugged more easily.
The ?? frames are, most likely, C functions for which there are no symbols -- certainly #16 and #17 are _start() and main(). #7 is likely some CF goober used for the -performSelector: internals.
It would be great if I could get gdb to do this for me.
I expect you should be able to. (I haven't done this for Objective-C, only for plain-C, but I can't imagine there will be any difference).
For C, suppose you want to teach GDB that foobar() is at address 0x12345678. Then:
echo 'void foobar() { }' | gcc -c -xc- -o foobar.o
(gdb) add-symbol-file foobar.o 0x12345678
(This works because in relocatable foobar.o the address of foobar() would normally be 0.)