I'm being rejected on the App Store for using private instance variables in my app. The ivars I am supposedly using are most definitely not being accessed in my code, but I am using one or two static libs from third parties. How would I test whether these could actually be the offenders?
Update:
Apple is accusing me (and 3rd party libs) of using private instance variables in the UITouch class, including
_locationInWindow
_tapCount
_previousLocationInWindow
_timestamp
_touchFlags
_phase
_window
I don't know anything about detecting the problem, but we encountered this problem recently; in our case it was caused by the Three20 library. If you are using it, see http://groups.google.com/group/three20/browse_thread/thread/c442af6e39a918b0/2375e7a158ee9d1b for a discussion/possible solutions.
You can use nm to scan for which library uses the ivar in question.
% nm static_lib.a | grep name_of_ivar
If you get a line, I think with a capital U, with the name of the ivar you probably have a suspect.
I am using one or two static libs
from third parties
Contact the third parties, requesting explanation, they wrote the code, they must know what's in there. They might have a forum or a comments section, where other users might have expressed these concerns already, and you can look for answers and alternatives.
For those who have many third-party libraries, can check your project in such a manner in your project path, for example if you want to find GraphicsService:
$ find . |grep "\\.a" | xargs grep GraphicsService
Related
Roald has written an excellent guide for the Twincat Eventlogger.
https://roald87.github.io/twincat/2020/11/03/twincat-eventlogger-plc-part.html
https://roald87.github.io/twincat/2021/01/20/twincat-eventlogger-hmi-part.html
For us this is exactly what we want, there is however 1 thing I haven't figured out. How to get the sourcename of the alarm in multiple languages in the HMI. params::sourceName gives the path in the software (example: MAIN.fbConveyor1.Cylinder1) This path can be customized when initializing the alarm (as Roald has shown). This doesn't work in my case, since I would like to define a generic alarm (example: "Cilinder not retracted within maximum time") that is instantiated multiple times.
I was thinking of using the source as a way to show the operator where the alarm occurs. We use this way (path) already for saving machine settings among other things. The machines we build are installed all over the world, so multilanguage is a must.
Beckhoff does support multilanguage alarm names (when defined), but the source is not defined, but dynamically generated.
Anyone have an idea how this problem can be solved?
If I understand your question correctly, then being able to parameterize the event text with information of the source of the problem should help you out.
If you define the event text as Cylinder {0} has not retracted in time. then you can add the arguments of that text during runtime.
IF bRaiseAlarm THEN
bRaiseAlarm := FALSE;
fbAlarm.ipArguments.Clear().AddString('Alice');
fbAlarm.Raise(0);
END_IF
However, since this also stated in the articles you mentioned, I am unsure if this would solve your problem.
'Alice' in this example, can be hard to localize. The following options come to my mind.
The string can be based on an ENUM. Enums can have textlist support, so if you add your translations there, that should allow multilingual output. However... this does require a lot of setup, placing translations inside your code, and making sure the PLC application is aware of the language that the parameter should use.
Use tags to mark the source device, as tags can be language invariant. It is not the most user-friendly method, but it could work for you. It would become something like: "Cylinder 'AA.1123' did not retract in time.". 'AA.1123' as a tag would have to be stored inside your PLC code as a string. You will have to trust that your operator can relate the tag back to the actual source.
Hopefully, this helped, or else please help me understand the problem better.
...and why has the package this misleading name (I assumed it had something to do with JavaME or mobile/smart phones)?
I found no references on the internet about scala.mobile.Code or scala.mobile.Location at all nor did I manage to do anything with those classes except getting ClassCastExcetions or NoSuchMethodErrors.
Actually there is not even a single test against scala.mobile in the Scala's test tree which could help understanding that code.
The classes really smell like they were forgotten in the source tree a long time ago and got accidentally released since that.
Maybe I just missed something about them?
Update:
scala.mobile was removed in Scala 2.9.
I just checked the source code.
When Scala changed the name mangling of class files a few years ago and it seems people forgot to update these classes accordingly.
So my answer would be:
At least Location has no purpose, because it is not possible to get anything sensible out of it (except exceptions) and Code without Location is severely limited. It works though if you pass the class literal to Code directly:
import scala.mobile._
val c = new Code(classOf[scala.collection.mutable.StringBuilder])
c.apply[StringBuilder, String]("append")("Foo")
c.apply[String]("toString")() // returns "Foo"
c.apply[Int]("length")() // returns 3
Looks like yet-another implementation in the standard library of reflection-slightly-nicer.
The description of Location pretty much explains what that is about:
The class Location provides a create method to instantiate objects
from a network location by specifying the URL address of the jar/class file.
It might be used by remote actors. Maybe.
As for why it has this misleading name? Well, back in 2004 smart phones had really low penetration, so maybe the association wasn't all that strong.
what is header file for the kernel API function kill_proc_info(int sig, struct siginfo *info, pid_t pid)
You can probably found this in linux/signal.c and include/linux/sched.h
Grep is your friend. Or use one of the cross-references like http://lxr.linux.no or http://www.cs.fsu.edu/~baker/devices/lxr/http/source/.
Ad edit (the original question did not say "API"):
Actually, that function is not an API. It's an implementation detail of signal.c. It is not an API, because there is no EXPORT_SYMBOL[_GPL] declaration for it, so it's not callable from modular code.
[edit]
man won't work - however, man kill_proc_info into your favorite search engine will. note too that posting a page that doesn't render correctly in somebodies browser will also result in a downvote.
[/edit]
man is your friend
[edit]
google is your friend (which is how I found the first answer - in the comments below) but we're not allowed to use that as an answer here. Better to have a repository of lazy people than to request they attempt to use the tools that they are given - IOW, better to give a man a fish than teach him how to fish
[/edit]
Now that Apple is running some kind of static analysis to automatically check for private API use, a number of people have been caught because of the Three20 library. I use another third-party library (which I compile myself from code) and I would like to automatically audit it for private API use before I submit to Apple, so I can eliminate/re-write those parts.
If I run nm on my application executable, I get a list of symbols, and I am seeing symbols in there that I don't use. For example I see _AudioServicesPlaySystemSound, and if I search for "AudioServicesPlaySystemSound" in XCode I get no results. Is there any way to automatically discriminate calls to private APIs, for example I notice that Apple has a habit of naming them with an initial underscore.
However: if I deliberately include a call to a private API it doesn't show up in the output of nm, but it does show up if I run strings on the binary. Based on this, one idea I had was to compile a huge list of all private API calls into a huge table, and automatically search for them in the strings output. I haven't done that yet.
Does anyone have any tips on how to automatically catch this stuff so I'm only going through the review process once?
You could try running nm on the object files instead of the linked executable:
nm -g -j *.o | sort | uniq
The objects should be in the build/<app>.build/*/<app>.build/Objects-normal sub-directory.
You're seeing a reference to AudioServicesPlaySystemSound because one of the functions you did call in turn calls AudioServicesPlaySystemSound.
Objective C calls won't generally show up in nm dumps, you'll need to use otool for that:
otool -ov <object file>
Use this dev tool, App Scanner. It scans your .app file for private API methods. A future release will also check for private API instance variables.
This is a little convoluted, but lets try:
I'm integrating LUA scripting into my game engine, and I've done this in the past on win32 in an elegant way. On win32 all I did was to mark all of the functions I wanted to expose to LUA as export functions. Then, to integrate them into LUA, I'd parse the PE header of the executable, unmangle the names, parse the parameters and such, then register them with my LUA runtime. This allowed me to avoid manually registering every function individually just to expose them to LUA.
Now, flash forward to today where I'm working on the iPhone. I've looked through some Unix stuff and I've gotten very close to taking a similar approach, however I'm not sure it will actually work.
I'm not entirely familiar with Unix, but here is what I have so far on iPhone:
Step 1: Query for the executable path through objective-C and get the path of my app
Step 2: Use dlopen to get a handle to my app using: `dlopen(path, RTLD_NOW)`
Step 3: Use `dlsym( libraryHandle, objectName )` to attempt to get the address of a known symbol.
The above steps won't actually get me to where I want to be, but even that doesn't work. Does anyone have any experience doing this type of thing on Unix? Are there any headers or functions I can google to put me on the right track?
Thanks;)
iPhone does not support dynamic linking after the initital application launch. While what you want to do does not actually require linking in any new application TEXT, it would not shock me to find out that some of the dl* functions do not behave as expected.
You may be able to write some platform specific code, but I recommend using a technique developed by the various BSDs called linker sets. Bascially you annotate the functions you want to do something with (just like you currently mark them for export). Through some preprocessor magic they store the annotations, sometimes in an extra segment in the binary image, then have code that grabs that data and enumerates its. So you simply add all the functions you want into the linker set, then walk through the linker set and register all the functions in it with lua.
I know people have gotten this stuff up and running on Windows and Linux, I have used it on Mac OS X and various *BSDs. I am linking the FreeBSD linker_set implementation, but I have not personally seen the Windows implementation.
You need to pass --export-dynamic to the linker (via -Wl,--export-dynamic).
Note: This is for Linux, but could be a starting point for your search.
References:
http://sourceware.org/binutils/docs/ld/Options.html
If static linking is an option, integrate that into the linker script. Before linking, do "nm" on all object files, extract the global symbols, and generate a C file containing a (preferably sorted/hashed) mapping of all symbol names to symbol values:
struct symbol{ char* name; void * value } symbols = [
{"foo", foo},
{"bar", bar},
...
{0,0}};
If you want to be selective in what you expose, it might be easiest to implement a naming schema, e.g. prefixing all functions/methods with Lua_.
Alternatively, you can create a trivial macro,
#define ForLua(X) X
and then grep the sources for ForLua, to select the symbols that you want to incorporate.
You could just generate a mapfile and use that instead, no?