In rare circumstances StackOverflows occur after aspecting Android projects

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

In rare circumstances StackOverflows occur after aspecting Android projects

Andreas Marschke
Hi all,

at work we are writing an analytics tool measuring network requests in
Android Applications leveraging AspectJ to measure them at runtime.

To that extend we have setup Aspects to run during a build of an Android
Application looking similar to the following:

pointcut URL_openConnection() : call(* java.net.URL.openConnection(..)) &&
  !within(org.example.metrics.android..*);

URLConnection around () : URL_openConnection()
{
  /* Do something interesting with this call */
  URLConnection connection = (URLConnection) proceed();

  /* Pass off the connection reference for internal bookkeeping */
  return connection;
}

In most cases this actually works flawlessly and has yet to result in a problem
in our test environment.

We do aspect both the build results (*.class-files) of the Application as well
as it's dependencies (ie. jars that the Android Application deems required at
compile/runtime to be available).

The problem begins when we received the report that this Aspect code resulted
in an unforeseen consequence of a StackOverflow (carefully reading the FAQ for
AspectJ and reviewing our Aspects I thought we would not have a similar case
to this one[0] at hand).

Receiving a compiled example of the project reporting the issue and not the code
I could clearly see in a decompiler 2 Aspects calling openConnection() where the
proceed() is and subsequently each other as aspect methods specifically.

This is curious to us and is something we have a hard time reproducing.

It would be of great help to us if someone from this forum who has more
experience could enlighten us as to what exactly is amiss here.

Thank you in advance,

Andreas Marschke


_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: In rare circumstances StackOverflows occur after aspecting Android projects

Alexander Kriegisch-2
Hi Andreas.

What is the "interesting thing" you are doing with the call?

How do you go about "internal bookkeeping"?

Why do you not have the source code of your program? Is it really a library instead of a stand-alone program? If so, who uses it for what purpose? And is it possible they are also using AspectJ?

The more details you can provide, the better we can help you.

Regards
-- 
Alexander Kriegisch


Am 04.07.2016 um 07:40 schrieb Andreas Marschke <[hidden email]>:

Hi all,

at work we are writing an analytics tool measuring network requests in
Android Applications leveraging AspectJ to measure them at runtime.

To that extend we have setup Aspects to run during a build of an Android
Application looking similar to the following:

pointcut URL_openConnection() : call(* java.net.URL.openConnection(..)) &&
  !within(org.example.metrics.android..*);

URLConnection around () : URL_openConnection()
{
  /* Do something interesting with this call */
  URLConnection connection = (URLConnection) proceed();

  /* Pass off the connection reference for internal bookkeeping */
  return connection;
}

In most cases this actually works flawlessly and has yet to result in a problem
in our test environment.

We do aspect both the build results (*.class-files) of the Application as well
as it's dependencies (ie. jars that the Android Application deems required at
compile/runtime to be available).

The problem begins when we received the report that this Aspect code resulted
in an unforeseen consequence of a StackOverflow (carefully reading the FAQ for
AspectJ and reviewing our Aspects I thought we would not have a similar case
to this one[0] at hand).

Receiving a compiled example of the project reporting the issue and not the code
I could clearly see in a decompiler 2 Aspects calling openConnection() where the
proceed() is and subsequently each other as aspect methods specifically.

This is curious to us and is something we have a hard time reproducing.

It would be of great help to us if someone from this forum who has more
experience could enlighten us as to what exactly is amiss here.

Thank you in advance,

Andreas Marschke

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: In rare circumstances StackOverflows occur after aspecting Android projects

Andreas Marschke
Hi Alexander, 

when the Aspect is called we are setting up a timer for the request, that's the interesting thing we do.

We are not allowed to get source of the customer application as there are legal issues in our way blocking direct access.

The internal bookkeeping tracks the URLConnection object for later retrieval so we can stop the timer set when the URLConnection is initiated.

We only provide an SDK to our customers and a Gradle plugin automating the aspect weaving. As far as we know no other code in their application or
dependency uses AspectJ. That is, we have received a list of dependencies the project requires both for building the project as well as for running it.
None of these requirements elude to AspectJ usage inside their project outside our integration.

We are monitoring network requests, and time user interactions based off of custom timers the developer may define. This is part of our Digital Performance Management offering.

Thanks,

Andreas Marschke.

On 4 July 2016 at 14:03, Alexander Kriegisch <[hidden email]> wrote:
Hi Andreas.

What is the "interesting thing" you are doing with the call?

How do you go about "internal bookkeeping"?

Why do you not have the source code of your program? Is it really a library instead of a stand-alone program? If so, who uses it for what purpose? And is it possible they are also using AspectJ?

The more details you can provide, the better we can help you.

Regards
-- 
Alexander Kriegisch


Am 04.07.2016 um 07:40 schrieb Andreas Marschke <[hidden email]>:

Hi all,

at work we are writing an analytics tool measuring network requests in
Android Applications leveraging AspectJ to measure them at runtime.

To that extend we have setup Aspects to run during a build of an Android
Application looking similar to the following:

pointcut URL_openConnection() : call(* java.net.URL.openConnection(..)) &&
  !within(org.example.metrics.android..*);

URLConnection around () : URL_openConnection()
{
  /* Do something interesting with this call */
  URLConnection connection = (URLConnection) proceed();

  /* Pass off the connection reference for internal bookkeeping */
  return connection;
}

In most cases this actually works flawlessly and has yet to result in a problem
in our test environment.

We do aspect both the build results (*.class-files) of the Application as well
as it's dependencies (ie. jars that the Android Application deems required at
compile/runtime to be available).

The problem begins when we received the report that this Aspect code resulted
in an unforeseen consequence of a StackOverflow (carefully reading the FAQ for
AspectJ and reviewing our Aspects I thought we would not have a similar case
to this one[0] at hand).

Receiving a compiled example of the project reporting the issue and not the code
I could clearly see in a decompiler 2 Aspects calling openConnection() where the
proceed() is and subsequently each other as aspect methods specifically.

This is curious to us and is something we have a hard time reproducing.

It would be of great help to us if someone from this forum who has more
experience could enlighten us as to what exactly is amiss here.

Thank you in advance,

Andreas Marschke

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users


_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: In rare circumstances StackOverflows occur after aspecting Android projects

Alexander Kriegisch-2
Hi Andreas.
 
It would be helpful if you could post some more info like aspect source code, weaving, application and error logs. My assumption for now is that you have more than one advice intercepting the same pointcut and at least two of them interfering with each other in an unhealty way. Depending on the way you set up and execute the timer that might also be the culprit, maybe something like calling proceed() multiple times (which is not necessarily a problem, but under certain circumstances might be).
--
Alexander Kriegisch
https://scrum-master.de
 

Andreas Marschke schrieb am 05.07.2016 16:25:

Hi Alexander, 
 
when the Aspect is called we are setting up a timer for the request, that's the interesting thing we do.
 
We are not allowed to get source of the customer application as there are legal issues in our way blocking direct access.
 
The internal bookkeeping tracks the URLConnection object for later retrieval so we can stop the timer set when the URLConnection is initiated.
 
We only provide an SDK to our customers and a Gradle plugin automating the aspect weaving. As far as we know no other code in their application or
dependency uses AspectJ. That is, we have received a list of dependencies the project requires both for building the project as well as for running it.
None of these requirements elude to AspectJ usage inside their project outside our integration.
 
We are monitoring network requests, and time user interactions based off of custom timers the developer may define. This is part of our Digital Performance Management offering.
 
Thanks,
 
Andreas Marschke.
 
On 4 July 2016 at 14:03, Alexander Kriegisch <[hidden email]> wrote:
Hi Andreas.
 
What is the "interesting thing" you are doing with the call?
 
How do you go about "internal bookkeeping"?
 
Why do you not have the source code of your program? Is it really a library instead of a stand-alone program? If so, who uses it for what purpose? And is it possible they are also using AspectJ?

The more details you can provide, the better we can help you.
 
Regards
-- 
Alexander Kriegisch
 
 

Am 04.07.2016 um 07:40 schrieb Andreas Marschke <[hidden email]>:
 
Hi all,
 
at work we are writing an analytics tool measuring network requests in
Android Applications leveraging AspectJ to measure them at runtime.
 
To that extend we have setup Aspects to run during a build of an Android
Application looking similar to the following:
 
pointcut URL_openConnection() : call(* java.net.URL.openConnection(..)) &&
  !within(org.example.metrics.android..*);
 
URLConnection around () : URL_openConnection()
{
  /* Do something interesting with this call */
  URLConnection connection = (URLConnection) proceed();
 
  /* Pass off the connection reference for internal bookkeeping */
  return connection;
}
 
In most cases this actually works flawlessly and has yet to result in a problem
in our test environment.
 
We do aspect both the build results (*.class-files) of the Application as well
as it's dependencies (ie. jars that the Android Application deems required at
compile/runtime to be available).
 
The problem begins when we received the report that this Aspect code resulted
in an unforeseen consequence of a StackOverflow (carefully reading the FAQ for
AspectJ and reviewing our Aspects I thought we would not have a similar case
to this one[0] at hand).
 
Receiving a compiled example of the project reporting the issue and not the code
I could clearly see in a decompiler 2 Aspects calling openConnection() where the
proceed() is and subsequently each other as aspect methods specifically.
 
This is curious to us and is something we have a hard time reproducing.
 
It would be of great help to us if someone from this forum who has more
experience could enlighten us as to what exactly is amiss here.
 
Thank you in advance,
 
Andreas Marschke
 
_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
 
 

_______________________________________________
aspectj-users mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Loading...