My Apk is receiving a sig_stop at epoll_wait. I am unable to figure out the part of code that is calling this. I know this is a part of libc.It tells me the line number for this epoll_wait . when I tried the tool addr2line , not much luck .
./toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi- addr2line -C -f -e ~/SoxPlayer/obj/local/armeabi/libc.so 0xafd0c75c
??
??:0
This is what I get ..
I want to know what part in my code is forking the thread 1 which calls the epoll_wait.
Thread [1] (Suspended: Signal 'SIGSTOP' received. Description: Stopped (signal).)
3 epoll_wait() 0xafd0c75c
2 <symbol is not available> 0xa8125706
1 <symbol is not available> 0xa8125706
Not much information here.
gdb will also provide the same information. ndk-stack tool wont help as I dont have the the kind of sigev fault or app crash which is needed for such a tool. My apk is waiting for the signal , event in my code. but what tool can I use to get who is calling epoll_wait in my code. I am able to see what is happening in my code but not able to pinpoint where exactly this epoll_wait gets called. Need advice about a tool I can use to figure this out.
Thanks
Related
I am running a C++ program that runs on several "processors" using MPI (mpirun (Open MPI) 4.0.1), a C++ lib that allows instances of a program to be launched on different processors and to communicate together.
For those familiar with the MPI librairy : what would you recommand me to do or to check to deal with the following error message ? Is this message refering to something very specific ?
A clue I have is that it could come from a blocking command (BSend, Brecv) waiting for a message from some of the nodes I am using, I know the code reaches its end then probably some functions are still waiting messages. Well it's just my guess because I could not find any information about "mpool" in the documentation.
Thanks in advance.
ERROR MESSAGE :
[1650458693.767260] [node010:51793:0] mpool.c:38 UCX WARN object 0x2ba6f718cf40 was not returned to mpool ucp_am_bufs
Post-scriptum : The code is thousand lines long, therefore I am not asking help to delve into it but rather advices to interpret this error message if it is a generic one. Thnx !
After a long investigation I figured out where the error came from.
I decided to reply myself to help anyone who would dig out a similar mistake. The question has been raised on the GitLab of MPI but never has been answered.
Long story short my "master" processor was MPI_Sending informations to the "slaves" processors. At the very same moment my "master" was sending these informations, all the slaves were turned-off, hence the "master" being angry not being answered.
Henceforth when MPI_Sending datas, I will (and I would recommand) check the status of the slaves CPUs.
i need to write a simple programm, to show a message every time a list of possible oID SNMP is received.
My list oID is:
oids = ['1.3.6.1.4.1.31448.1.1.0.9', '1.3.6.1.4.1.31448.1.1.0.13','1.3.6.1.4.1.31448.1.1.0.14','1.3.6.1.4.1.31448.1.1.0.15','1.3.6.1.4.1.31448.1.1.0.19','1.3.6.1.4.1.31448.1.1.0.23']
The reason is when PC receives one of these traps, there is a problem in device, and software must only show a warning. Nothing more.
thanks for your answer. I understand what you say and it´s so.
i explain what i have done.
SNMP version can be V1 orV2.
At the moment, i can´t paste python code, but i have tested with TrapAgentAddress='0.0.0.0' // TrapAgentAddress='127.0.0.1' but i don´t receive any message about receiving trap.
When i execute, it only show:
Agent is listening SNMP Trap on 0.0.0.0 , Port : 162
I know that i´m receiving traps, because i have received with WIRESHARK at same time.
I would like to insert an image, but i don´t know to do it. I have tried to paste python code, but i´m not be able to do it.
I´m very thanked for your support.
BR,
Antonio
I'm trying to found a more detailed and focused way to get error message from views in Tryton Client for speed development. I'm using
tryton -v -d -l DEBUG
but only bring UNICODE strings arriving to client. Is there a better approach?
I usually work with eclipse and pydev plugin. The installation is the same as OpenERP [1].
[1] http://domatix.com/entorno-desarrollo-eclipse-openerp-parte-tres/
Just like the client, the server can be run in verbose mode where stack traces are sent out to stderr and stdout. But this stack trace is no different from the unicode stack trace displayed by the tryton client. So the better way to debug once you find such an error would be to set a breakpoint around the code where the stacktrace frame indicates the exception occurred.
See: https://pythonconquerstheuniverse.wordpress.com/2009/09/10/debugging-in-python/ for a quick guide on pdb if you are using pdb for the first time.
OTOH, if you want to capture more information in production when exceptions occur, use the trytond-sentry integration module(See: http://www.openlabs.co.in/article/sentry-tryton-v-1-0)
Without going into too much detail (I am looking for debugging techniques here), I would like to understand how to better debug Xlib failed requests. In particular dealing with the glx extension. The occurrence of the bug I am fighting is in a complex place within my application and trying to pull it apart to provide a small sample here is not possible.
With that said the failed request I am seeing is
x10: fatal 10 error 11 (Resource temporarily unavailable) on X server ":0.0"
after 46 requests (46 know processed) with 0 event remaining.
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 135 (GLX)
Minor opcode of failed request: 5 (XGLMakeCurrent)
Serial number of failed request: 46
Current serial number in output stream: 46
I can see where the problem is being caused by stepping through with the debugger. However, I can't fully discern why it is happening.
The clue where to look is in the name of the extension and the name of the request itself. Unfortunately in this case because of your use of Xgl this isn't so helpful. But you can check what the request really is by checking out the protocol documentation like this one for glproto. From that you can see that the request is really glxMakeCurrent. Then you just need to find the documentation or code for that request.
The GLX specification says glxMakeCurrent will give BadAccess if "the context is current to some other thread".
Now, your error is about XGLMakeCurrent which is an implementation detail of Xgl . But from reading the implementation of this function it passes through to the the underlying GLX implementation.
To fix your problem I suggest you try and identify if that context is being used in another thread.
For debugging you want to turn on synchronous requests, this slows down your code but will make every X request wait until the server processes it before continuing and immediately return an error. You can turn it on with
XSynchronize(display, True);
Now you will get the X error at the routine that caused the issue and can use standard debugging tools from there.
A customer is reporting a connection failure with a strange profile: it apparently only fails for the very first URL request via CFNetwork since the app has launched.
The error code apparently being returned by CFNetwork is domain CFStreamErrorHTTP, but with error code -4, which does not correspond to any publicly defined error code for this domain.
In CFHTTPStream.h, the publicly defined error codes for CFStreamErrorHTTP end auspiciously at -3, strongly hinting that -4 may be an error code that Apple is using but which has not yet been publicly documented.
Any idea what's going on here? Has anybody else seen this error code and found rhyme or reason for it?
Probably not the final answer and this may have changed since they closed sourced CFNetwork, but I did find the following online which indicates that -4 is a connection lost error.
http://www.opensource.apple.com/source/CFNetwork/CFNetwork-129.9/HTTP/CFHTTPConnection.c
I guess you'll have to show some of the code that's failing, but a few questions spring to mind. First, can you trace this issue yourself, can you reproduce it? In particular, it would be interesting to see on which thread this happens, and what's the current runLoop mode. It could be indicative of a stream or connection that fails scheduling on the internal CF runloops.
Other than this (and it's a shame CFNetwork is no longer publicly updated), it could be a zillion things, but you'll need to log as much information as you can if you can't directly debug the failure (hint hint -- https://github.com/fpillet/NSLogger can help you remotely log the info from the client).
Finally, ask the question on Mac Dev Forums (or iOS Dev Forums if your code runs on iOS). Ping Quinn, He Knows It All. Once he can't publicly answer the question, open a DTS incident and send him the ticket #. He's the guy you want to look into your problem :-)