When I try to run the Perl debugger I'm getting a SEGV error:
Signal SEGV at /opt/csw/lib/perl/csw/Term/ReadLine/Gnu.pm line 240.
Term::ReadLine::Gnu::new("Term::ReadLine", "perldb", GLOB(0x81c1168), GLOB(0x81873a0)) called at /opt/csw/share/perl/5.10.1/perl5db.pl line 6073
DB::setterm called at /opt/csw/share/perl/5.10.1/perl5db.pl line 2237
DB::DB called at -e line 1
Abort (core dumped)
The errors takes place with any Perl code and I think is due to the debugger using Term::ReadLine::Gnu::new.
Using gdb to get the stack trace, I get the following:
Core was generated by `/opt/csw/bin/perl -de$a++'.
Program terminated with signal 6, Aborted.
#0 0xfeaabbc5 in kill () from /lib/libc.so.1
(gdb) bt
#0 0xfeaabbc5 in kill () from /lib/libc.so.1
#1 0xfef0c748 in Perl_apply () from /opt/csw/lib/i386/libperl.so
#2 0xfeeff1ee in Perl_pp_chown () from /opt/csw/lib/i386/libperl.so
#3 0xfeeb6721 in Perl_runops_standard () from /opt/csw/lib/i386/libperl.so
#4 0xfee570da in Perl_call_sv () from /opt/csw/lib/i386/libperl.so
#5 0xfeeac2c8 in Perl_sighandler () from /opt/csw/lib/i386/libperl.so
#6 0xfeea8173 in Perl_csighandler () from /opt/csw/lib/i386/libperl.so
#7 0xfeaa8ecf in __sighndlr () from /lib/libc.so.1
#8 0xfea9eb8f in call_user_handler () from /lib/libc.so.1
#9 <signal handler called>
#10 0xfe82b828 in baudrate () from /lib/libcurses.so.1
#11 0xfe7ede48 in _nc_setupterm () from /opt/csw/lib/libncurses.so.5
#12 0xfe7ee010 in tgetent () from /opt/csw/lib/libncurses.so.5
#13 0xfe88659a in _rl_init_terminal_io () from /opt/csw/lib/i386/libreadline.so.6
#14 0xfe86eb32 in readline_initialize_everything () from /opt/csw/lib/i386/libreadline.so.6
#15 0xfe86ea22 in rl_initialize () from /opt/csw/lib/i386/libreadline.so.6
#16 0xfe8d6e1d in XS_Term__ReadLine__Gnu__XS_rl_initialize () from /opt/csw/lib/perl/csw/auto/Term/ReadLine/Gnu/Gnu.so
#17 0xfeebe7ee in Perl_pp_entersub () from /opt/csw/lib/i386/libperl.so
#18 0xfeeb6721 in Perl_runops_standard () from /opt/csw/lib/i386/libperl.so
#19 0xfee568f1 in S_run_body () from /opt/csw/lib/i386/libperl.so
#20 0xfee56813 in perl_run () from /opt/csw/lib/i386/libperl.so
#21 0x08050b48 in main ()
I would greatly appreciate any help/clues.
Thanks!
Related
MarkLogic keeps crashing when I try to run cts.train() function.
Is it my code or something else? Can you help me figure out what's wrong?
MarkLogic Server 8.0-6.4
var labels = []
var voi = cts.collectionQuery(["VehicleOfInterest"])
for(var v in voi)
labels.push({classes:{name:"car"}})
v = cts.search(voi)
var all = [].concat.apply([], [v.toArray()])
var classifier = cts.train( all, labels, {classifierType: "supports", kernel:"simple", epsilon: 0.01} );
Sample node
<?xml version="1.0" encoding="UTF-8"?>
<root>
<RECORD__>1</RECORD__>
<ENTRY_DATE>2/15/2017</ENTRY_DATE>
<EXPIRY_DATE>2/15/2019</EXPIRY_DATE>
<VEHICLE_MAKE>Toyota</VEHICLE_MAKE>
<VEHICLE_MODEL>Corolla</VEHICLE_MODEL>
<VEHICLE_YEAR>2013</VEHICLE_YEAR>
<REGISTRATION>A29302843</REGISTRATION>
<VIN>1234134</VIN>
<LOCATION>MN</LOCATION>
<CLAIM_NUMBER>12345678</CLAIM_NUMBER>
<BACKGROUND___COMMENT>This is a test 1.</BACKGROUND___COMMENT>
<ORIGINAL_SOURCE>INFORMANT</ORIGINAL_SOURCE>
<RISK_CATEGORY>A1</RISK_CATEGORY>
<LINKED_PHONE__>9382938402</LINKED_PHONE__>
</root>
/var/opt/MarkLogic/Logs/ErrorLog.txt
Segmentation fault in thread 0x00007f6739864700
Thread 56 (Thread 0x7f67ec83d700 (LWP 6369)):
#0 0x00007f67e895379b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0
#1 0x00007f67e895382f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2 0x00007f67e89538cb in sem_wait##GLIBC_2.2.5 () from /lib64/libpthread.so.0
#3 0x0000000004322515 in svc::Semaphore::wait ()
#4 0x000000000433f151 in svc::StarterThread::run ()
#5 0x000000000434166e in svc::Thread::top ()
#6 0x00000000043428b9 in runThread ()
#7 0x00007f67e894ddc5 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f67e7d3e6ed in clone () from /lib64/libc.so.6
Thread 55 (Thread 0x7f67ec79f700 (LWP 6377)):
#0 0x00007f67e7d3fb7f in accept4 () from /lib64/libc.so.6
#1 0x000000000433087a in svc::Socket::accept ()
#2 0x000000000402c8bf in xdmp::XDQPServerThread::run ()
#3 0x000000000434166e in svc::Thread::top ()
#4 0x00000000043428b9 in runThread ()
#5 0x00007f67e894ddc5 in start_thread () from /lib64/libpthread.so.0
#6 0x00007f67e7d3e6ed in clone () from /lib64/libc.so.6
Thread 54 (Thread 0x7f67ec780700 (LWP 6378)):
#0 0x00007f67e8954bdd in nanosleep () from /lib64/libpthread.so.0
#1 0x000000000433ed12 in svc::Thread::sleep ()
#2 0x00000000024cffa2 in xdmp::ClusterManager::clusterThread ()
#3 0x000000000434166e in svc::Thread::top ()
#4 0x00000000043428b9 in runThread ()
#5 0x00007f67e894ddc5 in start_thread () from /lib64/libpthread.so.0
#6 0x00007f67e7d3e6ed in clone () from /lib64/libc.so.6
Thread 53 (Thread 0x7f673e7ff700 (LWP 6380)):
#0 0x00007f67e895379b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0
#1 0x00007f67e895382f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2 0x00007f67e89538cb in sem_wait##GLIBC_2.2.5 () from /lib64/libpthread.so.0
#3 0x0000000004322515 in svc::Semaphore::wait ()
#4 0x00000000043445a6 in svc::PooledThread::run ()
#5 0x000000000434166e in svc::Thread::top ()
#6 0x00000000043428b9 in runThread ()
#7 0x00007f67e894ddc5 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f67e7d3e6ed in clone () from /lib64/libc.so.6
...
objects in labels are just in wrong format,
i changed it to something like this and works fine now
labels.push({ "name": "voi doc",
"classes": [
{
"name": 'car',
"val": 1
}
]
})
I'm using AcePerl to download data from the wormbase.org database.
When I download certain database objects I get (after a certain number of objects) a segmentation fault. This behaviour is reproducible.
I had a look at the core dump and where prints a huge stack of function calls:
#0 0xb763c0ac in ?? () from /lib/i386-linux-gnu/libc.so.6
#1 0xb763eddc in malloc () from /lib/i386-linux-gnu/libc.so.6
#2 0x080c07ca in Perl_safesysmalloc ()
#3 0x080f3a02 in Perl_sv_grow ()
#4 0x080ebe38 in Perl_sv_setsv_flags ()
#5 0x080ecb76 in Perl_newSVsv ()
#6 0x0811516f in Perl_save_item ()
#7 0x080c7dd8 in Perl_get_db_sub ()
#8 0x080e7a4c in Perl_pp_entersub ()
#9 0x08075570 in Perl_call_sv ()
#10 0x080edd25 in Perl_sv_clear ()
#11 0x080ee3eb in Perl_sv_free2 ()
#12 0x080d79ec in Perl_hv_free_ent ()
#13 0x080d7c8c in ?? ()
#14 0x080db6ff in Perl_hv_undef_flags ()
#15 0x080edf72 in Perl_sv_clear ()
#16 0x080ee3eb in Perl_sv_free2 ()
#17 0x080d79ec in Perl_hv_free_ent ()
#18 0x080d7c8c in ?? ()
#19 0x080db6ff in Perl_hv_undef_flags ()
#20 0x080edf72 in Perl_sv_clear ()
#21 0x080ee3eb in Perl_sv_free2 ()
#22 0x080d79ec in Perl_hv_free_ent ()
#23 0x080d7c8c in ?? ()
#24 0x080db6ff in Perl_hv_undef_flags ()
#25 0x080edf72 in Perl_sv_clear ()
#26 0x080ee3eb in Perl_sv_free2 ()
#27 0x080d79ec in Perl_hv_free_ent ()
#28 0x080d7c8c in ?? ()
#29 0x080db6ff in Perl_hv_undef_flags ()
#30 0x080edf72 in Perl_sv_clear ()
#31 0x080ee3eb in Perl_sv_free2 ()
#32 0x080d79ec in Perl_hv_free_ent ()
#33 0x080d7c8c in ?? ()
#34 0x080db6ff in Perl_hv_undef_flags ()
#35 0x080edf72 in Perl_sv_clear ()
#36 0x080ee3eb in Perl_sv_free2 ()
#37 0x080d79ec in Perl_hv_free_ent ()
#38 0x080d7c8c in ?? ()
#39 0x080db6ff in Perl_hv_undef_flags ()
#40 0x080edf72 in Perl_sv_clear ()
#41 0x080ee3eb in Perl_sv_free2 ()
#42 0x080d79ec in Perl_hv_free_ent ()
#43 0x080d7c8c in ?? ()
#44 0x080db6ff in Perl_hv_undef_flags ()
#45 0x080edf72 in Perl_sv_clear ()
#46 0x080ee3eb in Perl_sv_free2 ()
#47 0x080d79ec in Perl_hv_free_ent ()
#48 0x080d7c8c in ?? ()
#49 0x080db6ff in Perl_hv_undef_flags ()
#50 0x080edf72 in Perl_sv_clear ()
#51 0x080ee3eb in Perl_sv_free2 ()
#52 0x080d79ec in Perl_hv_free_ent ()
#53 0x080d7c8c in ?? ()
...
These function calls are repeated thousands of time.
I also called perl -d:Trace myscript.pl > log but the logfile is about 3 GB large.
Is there a more convenient way to debug this script?
EDIT:
My script: http://paste.ubuntu.com/5564630/ .
My schema file: http://paste.ubuntu.com/5564631/ . It determines which data to download.
The seg fault is raised after ~2300 go_terms.
Install Devel::Trace.
Run your perl script with tracing enabled:
perl -d:Trace myscript.pl >trace 2>&1
Tail the file to see which Perl lines are executed leading up to the segmentation fault.
Very infrequently, our app is crashing because it receives SIGKILL. The circumstances are different, but the backtrace is always the same:
#0 0x94a00afa in mach_msg_trap ()
#1 0x94a01267 in mach_msg ()
#2 0x00fa9d5c in _UIPasteboardServerContainsTypesAtIndex ()
#3 0x00faa9ae in UIPasteboardServerContainsTypesAtIndex ()
#4 0x00fa5417 in -[UIPasteboard containsPasteboardTypes:] ()
#5 0x00de4054 in -[UITextField canPerformAction:withSender:] ()
#6 0x087038a8 in -[UIResponder(UITextAccessibilityUtilities) _accessibilityHasTextOperations] ()
#7 0x08704df5 in -[UIAccessibilityTextFieldElement _accessibilityHasTextOperations] ()
#8 0x08791dcf in -[NSObject(AXPrivCategory) accessibilityAttributeValue:] ()
#9 0x0878a3b4 in _copyMultipleAttributeValuesCallback ()
#10 0x087c5c95 in _AXXMIGCopyMultipleAttributeValues ()
#11 0x087c0a6c in _XCopyMultipleAttributeValues ()
#12 0x087c8e66 in mshMIGPerform ()
#13 0x020cf1c5 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#14 0x02034022 in __CFRunLoopDoSource1 ()
#15 0x0203290a in __CFRunLoopRun ()
#16 0x02031db4 in CFRunLoopRunSpecific ()
#17 0x02031ccb in CFRunLoopRunInMode ()
#18 0x02a43879 in GSEventRunModal ()
#19 0x02a4393e in GSEventRun ()
#20 0x00d2ba9b in UIApplicationMain ()
#21 0x0000284d in main (argc=1, argv=0xbfffed44) at [myapp]/main.m:14
#22 0x000027c5 in start ()
How would I go about finding out what is causing this crash?
The SIGKILL is sent to apps for any kind of exceptions. Se we have to make an educated guess what the exception reason would be in this case. In the above case it looks like accessibility is checking for a certain kind of pasteboard type to be present.
Since this is happening in Apple code most likely this is a bug in iOS, because the containsPasteboardTypes: method should never throw an exception. Only possibly if the passed parameter is nil, but then the bug would lie in UIAccessibilityTextFieldElement which too is Apple's responsibility.
Long story short: you need to file a radar. As a workaround you can add an #try block around the offending operation. This would catch and ignore the exception.
My app crashes only in simulator , it doesn't crash on device.
it crashes in simulator and gives me nothing except this :
#0 0x00000000 in 0x00000000 ()
#1 0x0182966e in icu::RuleBasedBreakIterator::handleNext ()
#2 0x018293dc in icu::RuleBasedBreakIterator::next() ()
#3 0x01828a12 in icu::RuleBasedBreakIterator::following(int) ()
#4 0x043378dd in WebCore::nextBreakablePosition(unsigned short const*, int, int, bool) ()
#5 0x04cc2fca in -[NSString(WebStringDrawing) __web_drawInRect:withFont:ellipsis:alignment:letterSpacing:lineSpacing:includeEmoji:truncationRect:measureOnly:renderedStringOut:] ()
#6 0x04cc07be in -[NSString(WebStringDrawing) __web_drawInRect:withFont:ellipsis:alignment:letterSpacing:lineSpacing:includeEmoji:truncationRect:measureOnly:] ()
#7 0x04cc0499 in -[NSString(WebStringDrawing) _web_drawInRect:withFont:ellipsis:alignment:lineSpacing:includeEmoji:truncationRect:measureOnly:] ()
#8 0x04cc021b in -[NSString(WebStringDrawing) _web_sizeInRect:withFont:ellipsis:lineSpacing:] ()
#9 0x0053fc33 in -[NSString(UIStringDrawing) sizeWithFont:constrainedToSize:lineBreakMode:lineSpacing:] ()
#10 0x00644987 in -[UILabel _drawTextInRect:baselineCalculationOnly:] ()
#11 0x006422fc in -[UILabel drawTextInRect:] ()
#12 0x00559187 in -[UIView(CALayerDelegate) drawLayer:inContext:] ()
#13 0x00221b5e in -[CALayer drawInContext:] ()
#14 0x0022de47 in backing_callback(CGContext*, void*) ()
#15 0x0017b1f7 in CABackingStoreUpdate ()
#16 0x0022dd24 in -[CALayer _display] ()
#17 0x0022427d in CALayerDisplayIfNeeded ()
#18 0x001c90c3 in CA::Context::commit_transaction(CA::Transaction*) ()
#19 0x001ca294 in CA::Transaction::commit() ()
#20 0x001ca555 in CA::Transaction::release_thread(void*) ()
#21 0x98f4de0c in _pthread_tsd_cleanup ()
#22 0x98f0664c in _pthread_exit ()
#23 0x98f069a0 in pthread_exit ()
#24 0x00c93d1a in -[NSString compare:options:] ()
#25 0x00c93c98 in __NSThread__main__ ()
#26 0x98f04ed9 in _pthread_start ()
#27 0x98f086de in thread_start ()
Why is this happening?
Thanks.
Set NSZombieEnabled, MallocStackLogging, and guard malloc in the debugger. Then, when your App crashes, type this in the gdb console:
(gdb) info malloc-history 0x543216
Replace 0x543216 with the address of the object that caused the crash, and you will get a much more useful stack trace and it should help you pinpoint the exact line in your code that is causing the problem.
See this article for more detailed instructions.
Another idea is to try turning off auto-correction in the simulator Settings App.
I'm using cocos2d and I load all my sprites and scenes before my game. However, once loaded, it seems if I click to start the game too quickly I get this crash:
malloc: *** error for object 0x65cdbb4: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
So I did what it suggested, recreated the crash and the stack shows this:
#0 0x9033df7e in malloc_error_break ()
#1 0x9033f128 in szone_error ()
#2 0x9033f29b in free_list_checksum_botch ()
#3 0x9024c186 in tiny_malloc_from_free_list ()
#4 0x9024b2a1 in szone_malloc_should_clear ()
#5 0x9024b148 in malloc_zone_malloc ()
#6 0x90249218 in malloc ()
#7 0x97145617 in operator new ()
#8 0x03adc43f in llvm::User::operator new ()
#9 0x03aab18f in llvm::CastInst::Create ()
#10 0x0341394c in llvm::BitcodeReader::ParseFunctionBody ()
#11 0x034164fe in llvm::BitcodeReader::materializeFunction ()
#12 0x0cd72472 in glvmAddOperation ()
#13 0x0cd4c752 in gleBuildVertexSubmitFunc ()
#14 0x0cd74e0c in cvmsModularBuilder ()
#15 0x03392a67 in cvmsCompBuildModularFunction ()
#16 0x033970a8 in cvmsServerBuildModularFunction ()
#17 0x03394e26 in CVMSBuildModularFunction ()
#18 0x032b0c26 in glvm_deferred_build_modular ()
#19 0x03310404 in glvmDoWork ()
#20 0x902747fd in _pthread_start ()
#21 0x90274682 in thread_start ()
None of these functions listed are mine, any ideas? Thanks.