When I launch Restlet J2SE on linux, I am getting the following exception. Any hint ?
java.lang.ArrayIndexOutOfBoundsException: 10
at java.util.concurrent.CopyOnWriteArrayList.addAllImpl(ILjava/util/Coll ection;)V [line 1048]
at java.util.concurrent.CopyOnWriteArrayList.addAll(Ljava/util/Collectio n;)Z [line 627]
at org.restlet.service.MetadataService.addCommonExtensions()V [line 371]
at org.restlet.service.MetadataService.<init>()V [line 84]
at org.restlet.Application.<init>(Lorg/restlet/Context;)V [line 172]
at org.restlet.Application.<init>()V [line 140]
Finally I managed to solve by editing the restlet sources in ,
org.restlet.service.MetadataService
// Add all those mappings
//Note : This is not working with in PowerPC with Aionix JVM
//this.mappings.addAll(dm);
//Adding one by one works fine.
for(MetadataExtension metadataExt : dm) {
this.mappings.add(metadataExt);
}
Related
I am seeing crashes via Crashlytics and hearing from customers that the application is crashing right as they open it.
This is narrowed down to the application migrating one of the realm databases. I have not been able to recreate the issue unfortunately because I am not able to make any sense of the error I am seeing.
I have logic that checks when the app starts up to check and see if the realm needs to be compacted. When doing that the realm determines that it needs to be migrated and hit the migration block.
config.migrationBlock = ^(RLMMigration *migration, uint64_t oldSchemaVersion) {
if (oldSchemaVersion < 17) {
[migration enumerateObjects:Event.className block:^(RLMObject *oldObject, RLMObject *newObject) {
NSString *className = [[oldObject[#"endDateTime"] objectSchema] className];
if ([className isEqualToString:#"DateObject"]) {
newObject[#"endDateTime"] = oldObject[#"endDateTime"][#"value"];
}
}];
}
};
Due to a mistake on my end when doing previous migrations I was manually checking to see if a property if of a specific type before deciding to migrate it.
Unfortunately when doing so the oldObject which should be of type RLMObject seems to be of type NSTaggedDate according to Crashlytics
[__NSTaggedDate objectSchema]: unrecognized selector sent to instance 0xe41bf592ee000000
Fatal Exception: NSInvalidArgumentException
0 CoreFoundation 0x186419d04 __exceptionPreprocess
1 libobjc.A.dylib 0x185668528 objc_exception_throw
2 CoreFoundation 0x1864271c8 __methodDescriptionForSelector
3 CoreFoundation 0x18641f6b0 ___forwarding___
4 CoreFoundation 0x18630501c _CF_forwarding_prep_0
5 MY_mobile_ios_common 0x10199c8c0 __34+[MYRealm getRealmConfigByName:]_block_invoke_2 (MYRealm.m:44)
6 Realm 0x1011b6598 -[RLMMigration enumerateObjects:block:] (RLMMigration.mm:99)
7 MY_mobile_ios_common 0x10199c830 __34+[MYRealm getRealmConfigByName:]_block_invoke (MYRealm.m:40)
8 Realm 0x1011b6ab4 -[RLMMigration execute:] (RLMMigration.mm:131)
9 Realm 0x1012297ec std::__1::__function::__func<+[RLMRealm realmWithConfiguration:error:]::$_1, std::__1::allocator<+[RLMRealm realmWithConfiguration:error:]::$_1>, void (std::__1::shared_ptr<realm::Realm>, std::__1::shared_ptr<realm::Realm>, realm::Schema&)>::operator()(std::__1::shared_ptr<realm::Realm>&&, std::__1::shared_ptr<realm::Realm>&&, realm::Schema&) (RLMRealm.mm:410)
10 Realm 0x10124fa90 std::__1::__function::__func<realm::Realm::update_schema(realm::Schema, unsigned long long, std::__1::function<void (std::__1::shared_ptr<realm::Realm>, std::__1::shared_ptr<realm::Realm>, realm::Schema&)>, std::__1::function<void (std::__1::shared_ptr<realm::Realm>)>, bool)::$_2, std::__1::allocator<realm::Realm::update_schema(realm::Schema, unsigned long long, std::__1::function<void (std::__1::shared_ptr<realm::Realm>, std::__1::shared_ptr<realm::Realm>, realm::Schema&)>, std::__1::function<void (std::__1::shared_ptr<realm::Realm>)>, bool)::$_2>, void ()>::operator()() (memory:4625)
11 Realm 0x101181f64 realm::ObjectStore::apply_schema_changes(realm::Group&, unsigned long long, realm::Schema&, unsigned long long, realm::SchemaMode, std::__1::vector<realm::SchemaChange, std::__1::allocator<realm::SchemaChange> > const&, std::__1::function<void ()>) (object_store.cpp:753)
12 Realm 0x10124bbb8 realm::Realm::update_schema(realm::Schema, unsigned long long, std::__1::function<void (std::__1::shared_ptr<realm::Realm>, std::__1::shared_ptr<realm::Realm>, realm::Schema&)>, std::__1::function<void (std::__1::shared_ptr<realm::Realm>)>, bool) (functional:1860)
13 Realm 0x101226a10 +[RLMRealm realmWithConfiguration:error:] (functional:1860)
14 MY_mobile_ios_common 0x10199cba0 +[MYRealm mainRealmCompact] (MYRealm.m:137)
15 MY App 0x1002b49dc -[AppDelegate compactRealmIfNeeded] (AppDelegate.m:808)
16 MY App 0x1002af940 -[AppDelegate application:didFinishLaunchingWithOptions:] (AppDelegate.m:48)
Any thoughts on what I could be doing wrong here, am about to just delete the realm databases and force the users to go back through the initial loading of data again.
ProductName: Mac OS X
ProductVersion: 10.12.6
BuildVersion: 16G1036
/Applications/Xcode.app/Contents/Developer
Xcode 9.1
Build version 9B55
/usr/local/bin/pod
1.3.1
Realm (2.10.2)
Realm (= 2.10.2)
/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16)
(not in use here)
/usr/local/bin/git
git version 2.12.2
The crash log is telling you that your call to [oldObject[#"endDateTime"] objectSchema] is seeing oldObject[#"endDateTime"] evaluate to an NSDate, which does not respond to -objectSchema. If the endDateTime property can be of different types depending on which schema version you're updating from, you'll need to do further checks on the object before sending -objectSchema to it.
Hi I wanted to install "1-Click Upgrade v1.6.7 - by PrestaShop" plugin, but I'm not able to because of the following error:
The following module(s) were not installed properly:
autoupgrade :
Unable to create the "AdminSelfUpgrade" tab
I have checked enabled modules and all of them are up to date and issued by PrestaShop. Could anybody help me, please?
I'm currently running PrestaShop™ 1.6.0.11.
Thanks for your help.
UPDATE: Turned on Error reporting:
[PrestaShopDatabaseException]
Unknown column 'hide_host_mode' in 'field list'
INSERT INTO `ps_tab` (`id_parent`, `position`, `module`, `class_name`, `active`, `hide_host_mode`) VALUES ('17', '10', 'autoupgrade', 'AdminSelfUpgrade', '1', '0')
at line 639 in file classes/db/Db.php
634. WebserviceRequest::getInstance()->setError(500, '[SQL Error] '.$this->getMsgError().'. From '.(isset($dbg[3]['class']) ? $dbg[3]['class'] : '').'->'.$dbg[3]['function'].'() Query was : '.$sql, 97);
635. }
636. elseif (_PS_DEBUG_SQL_ && $errno && !defined('PS_INSTALLATION_IN_PROGRESS'))
637. {
638. if ($sql)
639. throw new PrestaShopDatabaseException($this->getMsgError().'<br /><br /><pre>'.$sql.'</pre>');
640. throw new PrestaShopDatabaseException($this->getMsgError());
641. }
642. }
643.
644. /**
DbCore->displayError - [line 333 - classes/db/Db.php] - [1 Arguments]
DbCore->query - [line 613 - classes/db/Db.php] - [1 Arguments]
DbCore->q - [line 398 - classes/db/Db.php] - [2 Arguments]
DbCore->insert - [line 480 - classes/ObjectModel.php] - [3 Arguments]
ObjectModelCore->add - [line 103 - classes/Tab.php] - [2 Arguments]
TabCore->add - [line 442 - classes/ObjectModel.php] - [2 Arguments]
ObjectModelCore->save - [line 115 - classes/Tab.php]
TabCore->save - [line 74 - modules/autoupgrade/autoupgrade.php]
Autoupgrade->install - [line 828 - controllers/admin/AdminModulesController.php]
AdminModulesControllerCore->postProcessCallback - [line 1071 - controllers/admin/AdminModulesController.php]
AdminModulesControllerCore->postProcess - [line 171 - classes/controller/Controller.php]
ControllerCore->run - [line 374 - classes/Dispatcher.php]
DispatcherCore->dispatch - [line 54 - admin/index.php]
it would be a good idea if you turn on Error Reporting.
Also, do you have installed some 3rd party module that manage the admin tabs? Or at least a module that manage admin staff?
If that, try to uninstall it and delete the directory files.
Finally, I have solved it myself: There was a missing column in the ps_tab.
To fix it, you need to go to this MySQL table and add hide_host_mode column into the DV, it's a tinyint type.
Below is the output for "signature.rawPoints" with 32bit architecture Objective-C code
(
"NSRect: {{130, 142.5}, {2.3333333, 100}}",
"NSRect: {{136, 139.5}, {2.4990008, 101}}",
"NSRect: {{152.25, 131}, {2.0691545, 102}}",
"NSRect: {{169.75, 121}, {1.7328094, 103}}",
"NSRect: {{185.25, 111}, {1.5653242, 104}}",
"NSRect: {{196.125, 104}, {1.6099705, 105}}",
"NSRect: {{200.75, 101.375}, {1.9532523, 106}}"
),
But with 64bit architecture along with IOS8 below is the output
(
"\nlocation: 87.000000,112.000000\nvelocity: 0.000000,0.000000\nacceleration: 0.000000,0.000000\ntimestamp: 19476.794956\npressure: 1.000000\ndiameter: 4.666667\nid: 100",
"\nlocation: 88.000000,116.000000\nvelocity: 22.341108,89.364433\nacceleration: 499.125115,1996.500461\ntimestamp: 19476.839717\npressure: 1.000000\ndiameter: 5.006714\nid: 101",
"\nlocation: 92.000000,125.000000\nvelocity: 228.450167,514.012876\nacceleration: 11771.412252,24252.751985\ntimestamp: 19476.857226\npressure: 1.000000\ndiameter: 4.700317\nid: 102",
"\nlocation: 97.000000,134.000000\nvelocity: 298.178096,536.720573\nacceleration: 4158.268213,1354.187550\ntimestamp: 19476.873995\npressure: 1.000000\ndiameter: 4.437694\nid: 103")
The below code is not working with 64-bit architecture on the above rawpoints to find CGRectValues.
CGRect r1 = [[[signature.rawPoints objectAtIndex:i]objectAtIndex:j] CGRectValue];
Error:
2015-06-04 19:18:45.933 MySampleCloset UAT[40174:865394]
-[T1SignaturePoint CGRectValue]: unrecognized selector sent to instance 0x7f90d86b75a0 2015-06-04 19:18:45.977 MySampleCloset
UAT[40174:865394] *** Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: '-[T1SignaturePoint
CGRectValue]: unrecognized selector sent to instance 0x7f90d86b75a0'
Please suggest a solution.
Check your code carefully. Unrecognized selector means, that you try to use method to "wrong" object, like treating NSString as an NSArray for example, and sending NSString objectAtIndex message.
Or maybe, you using some kind of 3rd libraries, and they are not updated for 64 bit architecture.
If you want better answer then that, edit your code with CMD+K and show us your code..
TSignaturePoint.h added into the latest third point TSignature library, so we have to use the below code to find the x and y co ordinates for the signature of every letter.
CGPoint p = [[[signature.rawPoints objectAtIndex:i]objectAtIndex:j] location];
Note: [[signature.rawPoints objectAtIndex:i]objectAtIndex:j] is the type of TSignature.
we can also write the above as below
TSignature * sig = [[signature.rawPoints objectAtIndex:i]objectAtIndex:j];
CGPoint p = sig.location;
My (Cocoa)-App runs perfectly fine when I start it from within Xcode. However when I archive / release it, that version will crash. The error reporter that pops open says:
[...]
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Application Specific Information:
[9082] stack overflow
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff944a7212 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff9290caf4 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff92950e9e __abort + 159
3 libsystem_c.dylib 0x00007fff92951d17 __stack_chk_fail + 195
[...]
While it also gives me the line of code where execution stopped, this really does not help me as the exact same code path is executed in debug mode (but succeedes).
So I'm wondering: might it actually be that the stack sizes are different for a release and a debug version? And how big is the stack after all on a Mac (64 bit / Mountain Lion)? I'm not aware of putting insanely much data on the stack...
If I have too much data on the stack, what patterns would I need to avoid to reduce my stack load?
[Update]
ok, I got my App running by adding the -fno-stack-protector flag. (BTW: I'm compiling with LLVM)
Before that, I stepped through the crashing code line by line and found the following bahaviour which I don't understand:
the method foo(x) calls bacon(x). x is 8 and is handed from foo to bacon without modification. Yet when I step into bacon(x), x suddenly is 4295939448 (each time). If I set -fno-stack-protector the value is correct.
To my naive eyes, this looks as if the stack-protector sets the magic value 4295939448 somewhere in the stack and makes it read-only. And while my functions put their parameters on the stack, at some point parameter x happens to be put on that magic address and thus cannot be written (subsequent parameters seem to be written correctly). In my case x is a buffer length parameter, which naturally leads to a buffer-overflow and crash.
Does somebody have a deeper understanding of the stack-protector? Why is this happening? And in what cases is it safe and legal to disable the stack-protector and in what cases is it dangerous?
[Update 2: Original Code]
This method calls the other Decrypt below. stIVLen at that point is 8
BOOL CEracomSE::Decrypt(
PBYTE pMsg, size_t stLen,
const CSK* pKey /* = NULL */,
PBYTE pIV /* = NULL */, size_t stIVLen /* = 0 */,
FBM fbm /* = FBM_CBC */,
PADDING padding /* = NO_PADDING */
)
{
//stIVLen == 8
return Decrypt( (uint64_t)0, pMsg, stLen, pKey, pIV, stIVLen, fbm, padding );
}
When Decrypt is called stIVLen is 4295939448, the other parameter are still correct
BOOL CEracomSE::Decrypt(
uint64_t qwOffset,
PBYTE pMsg, size_t stLen,
const CSK* pKey /* = NULL */,
PBYTE pIV /* = NULL */, size_t stIVLen /* = 0 */,
FBM fbm /* = FBM_CBC */,
PADDING padding /* = NO_PADDING */
)
{
//stIVLen now is 4295939448
BYTE a_iv[16] = {0};
size_t a_iv_len;
BYTE a_key[32] = {0};
size_t a_key_len = 0;
size_t nBytes;
size_t nDataOffset;
size_t nRemainingData = stLen;
bool ret;
//[...]
}
I recently faced this situation with my app. I know its an old thread but responding anyways with the intent that someone else could benefit from the findings.
Passing -fno-stack-protector did solve the problem as suggested in the question. However, digging a little deeper we found that, changing all occurrences of literal array declaration to a longer declaration did solve the problem without passing the compiler flag.
so changing all occurrences of
#[#(1), #(2)]
to
[NSArray arrayWithObjects:#(1), #(2), nil]
May be its specific to our app only but hope it helps others as well.
Developing an app for OSX. There's still bugs and it crashes in release builds.
However, it runs in debug builds, when there's a blank NSLog statement in a few spots. If the NSLog statements are removed, the app crashes on run.
The first statement, in a run loop (prints calculated ticks and drawn frames, it simulates a fluid in an NSView)
NSLog(#"%d ticks, %d frames", ticks, frames);
The second statement, in the tick method that gets called every loop,
NSLog(#"");
In debug mode, running from Xcode, it works just fine with these two statements. If either is removed, it crashes. After several hours searching, I can't find any reference to apps crashing without blank NSLog statements.
Edit: The final question is: Is there anything I should look out for that might be causing this?
Edit 2: The run and tick methods are
-(void) run {
timeval start = gettime();
timeval end = gettime();
float dt = 1./60;
self.E.dt = dt;
float tick = 1e6*dt;
float unprocessed;
int ticks = 0;
int frames = 0;
timeval now;
while ( TRUE ) {
now = gettime();
unprocessed += diff(end, now)/tick;
end = now;
BOOL shouldRender = true; // set false to limit framerate to tickrate
while ( unprocessed >= 1 ) {
ticks++;
[self tick];
unprocessed -= 1;
shouldRender = true;
}
if ( shouldRender ) {
frames++;
}
if ( diff(start, gettime()) > 1000000 ) {
start.tv_sec += 1;
NSLog(#"%d ticks, %d frames", ticks, frames);
frames = 0;
ticks = 0;
}
}
}
-(void) tick {
NSLog(#"");
NSDictionary* fs = [NSDictionary dictionaryWithObjectsAndKeys:self.u, #"u", self.v, #"v", self.p, #"p", self.T, "#T", nil];
NSDictionary* gs = [self.E evolve:fs];
[self.u swap:[gs objectForKey:#"u"]];
[self.v swap:[gs objectForKey:#"v"]];
[self.p swap:[gs objectForKey:#"p"]];
[self.T swap:[gs objectForKey:#"T"]];
[self.view setNeedsDisplay:YES];
}
Edit 3: This is clearly an issue with LLVM. When I compile with GCC, I get no crash. Unfortunately there's an extraordinary amount of memory leaks now due to no ARC. Confusion level increased.
Edit 4: Backtrace
Crashed Thread: 2
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010
External Modification Warnings:
Debugger attached to process.
VM Regions Near 0x10:
-->
__TEXT 0000000103a9b000-0000000103a9c000 [ 4K] r-x/rwx SM=COW /Users/USER/Library/Developer/Xcode/DerivedData/Splash-ahjwbarsbqqbuzfcnxstxpslekdi/Build/Products/Debug/Splash.app/Contents/MacOS/Splash
Application Specific Information:
objc_msgSend() selector name: copy
objc[32100]: garbage collection is OFF
Thread 2 Crashed:
0 libobjc.A.dylib 0x00007fff8e43ee90 objc_msgSend + 16
1 com.apple.CoreFoundation 0x00007fff87edf8ac -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 668
2 com.apple.CoreFoundation 0x00007fff87efcd13 +[NSDictionary dictionaryWithObjectsAndKeys:] + 1203
3 com.mbarriault.Splash 0x0000000103a9d488 -[Game tick] + 328 (Game.m:95)
4 com.mbarriault.Splash 0x0000000103a9d2a9 -[Game run] + 361 (Game.m:76)
5 com.apple.Foundation 0x00007fff9020874e -[NSThread main] + 68
6 com.apple.Foundation 0x00007fff902086c6 __NSThread__main__ + 1575
7 libsystem_c.dylib 0x00007fff8dba18bf _pthread_start + 335
8 libsystem_c.dylib 0x00007fff8dba4b75 thread_start + 13
Thread 2 crashed with X86 Thread State (64-bit):
rax: 0x0000000103aa5a00 rbx: 0x0000000000000004 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000103aa3071 rsi: 0x00007fff8f9ea7d0 rbp: 0x0000000107b47970 rsp: 0x0000000107b47900
r8: 0x0000000000000004 r9: 0x0000000103aa5ab0 r10: 0x0000000000000001 r11: 0x0000000000000000
r12: 0x0000000000000003 r13: 0x0000000107b47928 r14: 0x0000000107b479a0 r15: 0x0000000107b47980
rip: 0x00007fff8e43ee90 rfl: 0x0000000000010202 cr2: 0x0000000000000010
Logical CPU: 3
I removed ID information and the logs for threads that didn't crash, as the whole log went over the post length limit.
Edit 5: Changing the dictionary creation from NSDictionary:dictionaryWithObjectsAndKeys: to NSDictionary:dictionaryWithObjects:forKeys: seems to have fixed all my problems. I'm not entirely certain why, but I'll take it! Thanks everyone!
Edit 6: The correct answer, believe if you will, was a simple typo in a string.
From the look of the backtrace it is crashing when allocating the NSDictionary. Probably one of the object references being used to initialize the NSDictionary is invalid. If you post code from the tick method it could help narrow down what the problem is. Also, if you try debugging with NSZombie on it could tell us which object type it is crashing on.
Edit:
OK. Now that I see the tick code, I can see the problem. I didn't see it at first, but you are using the c-string "#T", which you probably intended to be #"T".