Search Results

Search found 9137 results on 366 pages for 'worker thread'.

Page 28/366 | < Previous Page | 24 25 26 27 28 29 30 31 32 33 34 35  | Next Page >

  • COM port read - Thread remains alive after timeout occurs

    - by Sna
    Hello to all. I have a dll which includes a function called ReadPort that reads data from serial COM port, written in c/c++. This function is called within an extra thread from another WINAPI function using the _beginthreadex. When COM port has data to be read, the worker thread returns the data, ends normaly, the calling thread closes the worker's thread handle and the dll works fine. However, if ReadPort is called without data pending on the COM port, when timeout occurs then WaitForSingleObject returns WAIT_TIMEOUT but the worker thread never ends. As a result, virtual memory grows at about 1 MB every time, physical memory grows some KBs and the application that calls the dll becomes unstable. I also tryied to use TerminateThread() but i got the same results. I have to admit that although i have enough developing experience, i am not familiar with c/c++. I did a lot of research before posting but unfortunately i didn't manage to solve my problem. Does anyone have a clue on how could i solve this problem? However, I really want to stick to this kind of solution. Also, i want to mention that i think i can't use any global variables to use some kind of extra events, because each dll's functions may be called many times for every COM port. I post some parts of my code below: The Worker Thread: unsigned int __stdcall ReadPort(void* readstr){ DWORD dwError; int rres;DWORD dwCommModemStatus, dwBytesTransferred; int ret; char szBuff[64] = ""; ReadParams* params = (ReadParams*)readstr; ret = SetCommMask(params->param2, EV_RXCHAR | EV_CTS | EV_DSR | EV_RLSD | EV_RING); if (ret == 0) { _endthreadex(0); return -1; } ret = WaitCommEvent(params->param2, &dwCommModemStatus, 0); if (ret == 0) { _endthreadex(0); return -2; } ret = SetCommMask(params->param2, EV_RXCHAR | EV_CTS | EV_DSR | EV_RLSD| EV_RING); if (ret == 0) { _endthreadex(0); return -3; } if (dwCommModemStatus & EV_RXCHAR||dwCommModemStatus & EV_RLSD) { rres = ReadFile(params->param2, szBuff, 64, &dwBytesTransferred,NULL); if (rres == 0) { switch (dwError = GetLastError()) { case ERROR_HANDLE_EOF: _endthreadex(0); return -4; } _endthreadex(0); return -5; } else { strcpy(params->param1,szBuff); _endthreadex(0); return 0; } } else { _endthreadex(0); return 0; } _endthreadex(0); return 0;} The Calling Thread: int WINAPI StartReadThread(HANDLE porthandle, HWND windowhandle){ HANDLE hThread; unsigned threadID; ReadParams readstr; DWORD ret, ret2; readstr.param2 = porthandle; hThread = (HANDLE)_beginthreadex( NULL, 0, ReadPort, &readstr, 0, &threadID ); ret = WaitForSingleObject(hThread, 500); if (ret == WAIT_OBJECT_0) { CloseHandle(hThread); if (readstr.param1 != NULL) // Send message to GUI return 0; } else if (ret == WAIT_TIMEOUT) { ret2 = CloseHandle(hThread); return -1; } else { ret2 = CloseHandle(hThread); if (ret2 == 0) return -2; }} Thank you in advance, Sna.

    Read the article

  • [gtk+] run function in another thread than gui

    - by sterh
    Hello, I have simple C/gtk+ application. I have function in this app which load image in gtkimageview widget: gboolean main_win_open( MainWin* mw, const char* file_path) { ... //loading and displaing image in gtkimageview ... } The loading image is work, but i need to run this function in another thread then main gui form; I have function: void* argument_thread(void *args) { Data *data = (Data*)args; gdk_threads_enter(); main_win_open (data->win,data->argv); gdk_threads_leave(); } Data it's structure for main_win_open function arguments: typedef struct _Data { MainWin *win; char* argv; } Data; Then in main function i create thread and run it: int main(int argc, char** argv) { GError* err; GThread* thread; Data data; MainWin *win; // init thread support if(!g_thread_supported()) g_thread_init(NULL); gdk_threads_init(); // init GTK+ gtk_init (&argc, &argv); win = (MainWin*)main_win_new(); gtk_widget_show(GTK_WIDGET(win)); data.win = win; data.argv = argv[1]; if (argc == 2) { thread = g_thread_create((GThreadFunc)argument_thread,&data,FALSE, &err); } gdk_threads_enter(); gtk_main(); gdk_threads_leave(); } But when i try to run app from command line and try to load big-size image, gui is blocking. What's wrong? Thank you.

    Read the article

  • Thread in android

    - by ravi adhikari
    Hi experts, I need some help as i am just calling a method in a thread. now what i want is wait for reply form getData() method only for 15 seconds. If it reply before 15 seconds it should be terminated otherwise after 15 seconds it should be terminated. The code is given below: boolean networkStatus; private Runnable runnable; private ProgressDialog m_ProgressDialog = null; private Runnable returnRes = new Runnable() { @Override public void run() { if(networkStatus){ setData(); m_ProgressDialog.dismiss(); } }; private void callGetdata(){ runnable = new Runnable() { @Override public void run() { networkStatus = getData(); runOnUiThread(returnRes); } }; Thread thread = new Thread(null, runnable, "MovetoBackground"); thread.start(); m_ProgressDialog = ProgressDialog.show(this, "", getString(R.string.loadMsg), true); }

    Read the article

  • Invoke target throwing invalid cross-thread operate exception

    - by sqwerty
    MethodInfo mi = typeof(NotifyIcon).GetMethod("ShowContextMenu", BindingFlags.Instance | BindingFlags.NonPublic); mi.Invoke(notify, null); This throws the following exception: {"Exception has been thrown by the target of an invocation."} With the following inner exception: "Cross-thread operation not valid: Control '' accessed from a thread other than the thread it was created on." If I comment out a line of code that sets the images for the context menu entries then it stops throwing the exception. Any ideas?

    Read the article

  • Thread Jobs in Java

    - by Bragaadeesh
    Hi, I want to spawn 200 threads simultaneously in Java. What I'm doing right now is running into a loop and creating 200 threads and starting them. After these 200 gets completed, I want to spawn another 200 set of threads and so on. The gist here is that the first 200 threads I spawned need to be FINISHED before spawning the next set. I tried the code below, but its not working for(int i=0;i<200;i++){ Thread myThread = new Thread(runnableInstance); myThread.start(); } for(int i=0;i<200;i++){ Thread myThread = new Thread(runnableInstance); myThread.start(); } Note: I have intentionally put the for loop Twice, but the desired effect I intend is not happening simply because the second for loop is executed before the first set of threads end their execution. Please advise

    Read the article

  • Thread is being killed by the OS

    - by Or.Ron
    I'm currently programming an app that extracts frames from a movie clip. I designed it so that the extraction will be done on a separate thread to prevent the application from freezing. The extraction process itself is taking a lot of resources, but works fine when used in the simulator. However, there are problems when building it for the iPad. When I perform another action (I'm telling my AV player to play while I extract frames), the thread unexpectedly stops working, and I believe it's being killed. I assume it's becauase I'm using a lot of resources, but not entirely sure. Here are my questions: 1. How can I tell if/why my thread stopping? 2. If it's really from over processing what should I do? I really need this action to be implemented. Heres some code im using: To create the thread: [NSThread detachNewThreadSelector:@selector(startReading) toTarget:self withObject:nil]; I'll post any information you need, Thanks so much! Update I'm using GCD now and it populates the threads for me. However the OS still kills the threads. I know exactly when is it happening. when i tell my [AVplayer play]; it kills the thread. This issue is only happening in the actual iPad and not on the simulator

    Read the article

  • How can i pass an object to a new thread generated anonymously in a button listener

    - by WaterBoy
    I would like to pass an object (docket for printing) to a new thread which will print the docket. My code is: private final Button.OnClickListener cmdPrintOnClickListener = new Button.OnClickListener() { public void onClick(View v) { new Thread(new Runnable() { public void run() { enableTestButton(false); Looper.prepare(); doConnectionTest(); Looper.loop(); Looper.myLooper().quit(); } }).start(); } }; How do I pass the object to it? Also - I need to generate the object in the UI thread, just before starting the new thread so where could I put this method (e.g. getDocketObject()) in relation to my code below thanks, anton

    Read the article

  • .NET Threading : How to wait for other thread to finish some task

    - by Alex Ilyin
    Assume I have method void SomeMethod(Action callback) This method does some work in background thread and then invokes callback. The question is - how to block current thread until callback is called ? There is an example bool finished = false; SomeMethod(delegate{ finished = true; }); while(!finished) Thread.Sleep(); But I'm sure there should be better way

    Read the article

  • Interrupt a thread in DatagramSocket.receive

    - by SEK
    I'm building an application that listens on both TCP and UDP, and I've run into some trouble with my shutdown mechanism. When I call Thread.interrupt() on each of the listening threads, the TCP thread is interrupted from listening, whereas the UDP listener isn't. To be specific, the TCP thread uses Socket.accept(), which simply returns (without actually connecting). Whereas the UDP thread uses DatagramSocket.receive, and doesn't exit that method. Is this an issue in my JRE, my OS, or should I just switch to (Datagram)Socket.close()?

    Read the article

  • C# background worker and timer loop

    - by Mike
    This is my first attempt of a Timer, if someone could help me out where I am going wrong it would be awesome. I'm trying to use a while loop where if the timer hits 30 seconds try to loop it again. private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e) { System.Windows.Forms.Timer my_timer = new System.Windows.Forms.Timer(); my_timer = null; //int restartticker = 30000; while (true) { my_timer.Start(); if (my_timer.Equals(30000)) { watcherprocess1(); } my_timer = null; } } Object reference not set to an instance of an object. my_timer.Start();

    Read the article

  • std::thread and class constructor and destructor

    - by toeplitz
    When testing threads in C++11 I have created the following example: #include <iostream> #include <thread> class Foo { public: Foo(void) { std::cout << "Constructor called: " << this << std::endl; } ~Foo(void) { std::cout << "Destructor called: " << this << std::endl; } void operator()() const { std::cout << "Operatior called: " << this << std::endl; } }; void test_normal(void) { std::cout << "====> Standard example:" << std::endl; Foo f; } void test_thread(void) { std::cout << "====> Thread example:" << std::endl; Foo f; std::thread t(f); t.detach(); } int main(int argc, char **argv) { test_normal(); test_thread(); for(;;); } Which prints the following: Why is the destructor called 6 times for the thread? And why does the thread report different memory locations?

    Read the article

  • Rerunning DoWork on Background Worker Based on Result?

    - by Soo
    Let's say I have a backgroundWorker1_DoWork that finds a value in a database and returns it in e.Result. Let's say I also have a backgroundWorker1_RunWorkerCompleted that reads the result. What I want to be able to do is based on e.Result, I can re-run backgroundWorker1_DoWork, and this I am not sure how to do. I'd really appreciate any help.

    Read the article

  • C# Events between threads executed in their own thread (How to) ?

    - by Guillaume
    Hello, I'd like to have two Threads. Let's call them : Thread A Thread B Thread A fires an event and thread B listen to this event. When the Thread B Event Listener is executed, it's executed with the Thread A's thread ID, so i guess it is executed within the Thread A. What I'd like to do is be able to fire event to Thread B saying something like: "hey, a data is ready for you, you can deal with it now". This event must be executed in its own Thread because it uses things that only him can access (like UI controls). How can I do that ? Thank you for you help.

    Read the article

  • Threading in java vs C#

    - by ffayyaz
    I need a little confirmation over something i am confused at . I know how threads work in java. new DialList(string a , string b).start(); // where DialList is a class public class DialList extends Thread { public DialList(String a, string b) { FilePath = a; ThreadLogFile = b"; } public void run() { // some code to run in different thread } } Now i want to run same code in C# , Shall i put the code which is in run() into a method and do something like Thread t = new Thread (runcsharp); // Kick off a new thread t.Start(); static void runcsharp() { // code } or is there some other way to do it ?

    Read the article

  • one timer per thread using Qt

    - by Pourya
    Hi, I modified Qt's broadcast sender example so that it has ten threads and in each thread it starts a timer, but only timer of the first thread is triggered. How can I have one timer running for each thread?

    Read the article

  • Java Thread wait() => blocked?

    - by Chris
    According to http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.State.html calling wait() will result a thread to go in BLOCKED state. However this piece of code will result (after being called) in a Thread in WAITING State. class bThread extends Thread { public synchronized void run() { try { wait(); } catch (InterruptedException e) { e.printStackTrace(); } } } Have I got something wrong? Can anybody explain this behaviour to me? Any help would be appreciated!

    Read the article

  • Trouble linking libboost libraries to compile sslsniff on RHEL

    - by rwong48
    Trying to build sslsniff on a RHEL 5.2 system here. When compiling sslsniff on RHEL I hit the same errors when using libboost packages (from repositories like rpmforge) and compiling libboost from source (which appeared to be successful.) I tried this on a fresh system as well (no previous/failed/garbage installs of libboost etc.) # make g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT SSLConnectionManager.o -MD -MP -MF .deps/SSLConnectionManager.Tpo -c -o SSLConnectionManager.o SSLConnectionManager.cpp mv -f .deps/SSLConnectionManager.Tpo .deps/SSLConnectionManager.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT FirefoxUpdater.o -MD -MP -MF .deps/FirefoxUpdater.Tpo -c -o FirefoxUpdater.o FirefoxUpdater.cpp mv -f .deps/FirefoxUpdater.Tpo .deps/FirefoxUpdater.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT Logger.o -MD -MP -MF .deps/Logger.Tpo -c -o Logger.o Logger.cpp mv -f .deps/Logger.Tpo .deps/Logger.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT SessionCache.o -MD -MP -MF .deps/SessionCache.Tpo -c -o SessionCache.o SessionCache.cpp mv -f .deps/SessionCache.Tpo .deps/SessionCache.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT SSLBridge.o -MD -MP -MF .deps/SSLBridge.Tpo -c -o SSLBridge.o SSLBridge.cpp mv -f .deps/SSLBridge.Tpo .deps/SSLBridge.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT HTTPSBridge.o -MD -MP -MF .deps/HTTPSBridge.Tpo -c -o HTTPSBridge.o HTTPSBridge.cpp mv -f .deps/HTTPSBridge.Tpo .deps/HTTPSBridge.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT sslsniff.o -MD -MP -MF .deps/sslsniff.Tpo -c -o sslsniff.o sslsniff.cpp mv -f .deps/sslsniff.Tpo .deps/sslsniff.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT FingerprintManager.o -MD -MP -MF .deps/FingerprintManager.Tpo -c -o FingerprintManager.o FingerprintManager.cpp mv -f .deps/FingerprintManager.Tpo .deps/FingerprintManager.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT AuthorityCertificateManager.o -MD -MP -MF .deps/AuthorityCertificateManager.Tpo -c -o AuthorityCertificateManager.o `test -f 'certificate/AuthorityCertificateManager.cpp' || echo './'`certificate/AuthorityCertificateManager.cpp mv -f .deps/AuthorityCertificateManager.Tpo .deps/AuthorityCertificateManager.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT TargetedCertificateManager.o -MD -MP -MF .deps/TargetedCertificateManager.Tpo -c -o TargetedCertificateManager.o `test -f 'certificate/TargetedCertificateManager.cpp' || echo './'`certificate/TargetedCertificateManager.cpp mv -f .deps/TargetedCertificateManager.Tpo .deps/TargetedCertificateManager.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT CertificateManager.o -MD -MP -MF .deps/CertificateManager.Tpo -c -o CertificateManager.o `test -f 'certificate/CertificateManager.cpp' || echo './'`certificate/CertificateManager.cpp mv -f .deps/CertificateManager.Tpo .deps/CertificateManager.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT HttpBridge.o -MD -MP -MF .deps/HttpBridge.Tpo -c -o HttpBridge.o `test -f 'http/HttpBridge.cpp' || echo './'`http/HttpBridge.cpp mv -f .deps/HttpBridge.Tpo .deps/HttpBridge.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT HttpConnectionManager.o -MD -MP -MF .deps/HttpConnectionManager.Tpo -c -o HttpConnectionManager.o `test -f 'http/HttpConnectionManager.cpp' || echo './'`http/HttpConnectionManager.cpp mv -f .deps/HttpConnectionManager.Tpo .deps/HttpConnectionManager.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT HttpHeaders.o -MD -MP -MF .deps/HttpHeaders.Tpo -c -o HttpHeaders.o `test -f 'http/HttpHeaders.cpp' || echo './'`http/HttpHeaders.cpp mv -f .deps/HttpHeaders.Tpo .deps/HttpHeaders.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT UpdateManager.o -MD -MP -MF .deps/UpdateManager.Tpo -c -o UpdateManager.o UpdateManager.cpp mv -f .deps/UpdateManager.Tpo .deps/UpdateManager.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT OCSPDenier.o -MD -MP -MF .deps/OCSPDenier.Tpo -c -o OCSPDenier.o `test -f 'http/OCSPDenier.cpp' || echo './'`http/OCSPDenier.cpp mv -f .deps/OCSPDenier.Tpo .deps/OCSPDenier.Po g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"sslsniff\" -DVERSION=\"0.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -ggdb -g -O2 -MT FirefoxAddonUpdater.o -MD -MP -MF .deps/FirefoxAddonUpdater.Tpo -c -o FirefoxAddonUpdater.o FirefoxAddonUpdater.cpp mv -f .deps/FirefoxAddonUpdater.Tpo .deps/FirefoxAddonUpdater.Po g++ -ggdb -g -O2 -lssl -lboost_filesystem -lpthread -lboost_thread -llog4cpp -o sslsniff SSLConnectionManager.o FirefoxUpdater.o Logger.o SessionCache.o SSLBridge.o HTTPSBridge.o sslsniff.o FingerprintManager.o AuthorityCertificateManager.o TargetedCertificateManager.o CertificateManager.o HttpBridge.o HttpConnectionManager.o HttpHeaders.o UpdateManager.o OCSPDenier.o FirefoxAddonUpdater.o SSLConnectionManager.o: In function `__static_initialization_and_destruction_0': /usr/local/include/boost/system/error_code.hpp:208: undefined reference to `boost::system::get_system_category()' /usr/local/include/boost/system/error_code.hpp:209: undefined reference to `boost::system::get_generic_category()' /usr/local/include/boost/system/error_code.hpp:214: undefined reference to `boost::system::get_generic_category()' /usr/local/include/boost/system/error_code.hpp:215: undefined reference to `boost::system::get_generic_category()' /usr/local/include/boost/system/error_code.hpp:216: undefined reference to `boost::system::get_system_category()' There's more, but I guess there's a post length limit.. Most of them appear related to boost::system so I added -lboost_system to the linker command and got farther: # g++ -ggdb -g -O2 -lssl -lboost_filesystem -lpthread -lboost_thread -llog4cpp -o sslsniff SSLConnectionManager.o FirefoxUpdater.o Logger.o SessionCache.o SSLBridge.o HTTPSBridge.o sslsniff.o FingerprintManager.o AuthorityCertificateManager.o TargetedCertificateManager.o CertificateManager.o HttpBridge.o HttpConnectionManager.o HttpHeaders.o UpdateManager.o OCSPDenier.o FirefoxAddonUpdater.o -lboost_system SSLConnectionManager.o: In function `thread<boost::_bi::bind_t<void, boost::_mfi::mf3<void, SSLConnectionManager, boost::shared_ptr<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::ip::basic_endpoint<boost::asio::ip::tcp>, bool>, boost::_bi::list4<boost::_bi::value<SSLConnectionManager*>, boost::_bi::value<boost::shared_ptr<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > > >, boost::_bi::value<boost::asio::ip::basic_endpoint<boost::asio::ip::tcp> >, boost::_bi::value<bool> > > >': /usr/local/include/boost/thread/detail/thread.hpp:191: undefined reference to `boost::thread::start_thread()' SSLConnectionManager.o: In function `~thread_data': /usr/local/include/boost/thread/detail/thread.hpp:40: undefined reference to `boost::detail::thread_data_base::~thread_data_base()' /usr/local/include/boost/thread/detail/thread.hpp:40: undefined reference to `boost::detail::thread_data_base::~thread_data_base()' /usr/local/include/boost/thread/detail/thread.hpp:40: undefined reference to `boost::detail::thread_data_base::~thread_data_base()' /usr/local/include/boost/thread/detail/thread.hpp:40: undefined reference to `boost::detail::thread_data_base::~thread_data_base()' Now the errors are related to boost::detail and boost::filesystem::detail. I've tried using boost 1.35 and 1.42 (latest). On my own Ubuntu system, I installed the libraries from Ubuntu repositories and I was able to compile+link sslsniff just fine. Thanks in advance.

    Read the article

  • Threading in Android

    - by virsir
    I am currently developing Android app, it needs download content from internet. I use thread to do that and then call runOnUiThread method to update GUI. I placed a refresh menu on it, if user tried to refresh the content, the download thread will be created and started. The problem is that how can I control the thread order, I need to accept the latest request's response and abandon previous thread requests if there were some other requests still running because the request parameters may have been changed by user. Currently I was using a threadId to do this thing, when a thread finished, it will check its threadId, if it was the latest recored one, it then takes control and render the response. My question is that is there any other proper better solution for this? Do I need to stop threads when user exit the app? I remember that some book said that do not try stop thread manually and wait itself finish is a good practice, is that true? Should I stop them by calling "stop" or "interrupt" method? I read some documents around threading in Android and found the class HandlerThread, what is it? In what kind of situation I need to use it?

    Read the article

  • Multithreading: Read from / write to a pipe

    - by Tero Jokinen
    I write some data to a pipe - possibly lots of data and at random intervals. How to read the data from the pipe? Is this ok: in the main thread (current process) create two more threads (2, 3) the second thread writes sometimes to the pipe (and flush-es the pipe?) the 3rd thread has infinite loop which reads the pipe (and then sleeps for some time) Is this so far correct? Now, there are a few thing I don't understand: do I have to lock (mutex?) the pipe on write? IIRC, when writing to pipe and its buffer gets full, the write end will block until I read the already written data, right? How to check for read data in the pipe, not too often, not too rarely? So that the second thread wont block? Is there something like select for pipes? It is possible to set the pipe to unbuffered more or I have to flush it regularly - which one is better? Should I create one more thread, just for flushing the pipe after write? Because flush blocks as well, when the buffer is full, right? I just don't want the 1st and 2nd thread to block.... [Edit] Sorry, I thought the question is platform agnostic but just in case: I'm looking at this from Win32 perspective, possibly MinGW C...

    Read the article

  • iTunes 9.0.2 hangs on launch on Mac OS X 10.6.2

    - by dlamblin
    My iTunes 9.0.2 hangs on launch in OS X 10.6.2. This doesn't happen all the time, only if I've been running for a while. Then it will recur until I restart. Similarly Safari 4.0.4 will hang in the flash player plugin when about to play a video. If I restart both these problems go away until later. Based on this crash dump I am suspecting Audio Hijack Pro. I will try to install a newer version of the driver involved, but so far I haven't had much luck. I have uninstalled the Flash Plugin (10.0.r42 and r32) but clearly I want it in the long run. This is iTunes' crash report. Date/Time: 2009-12-14 19:56:02 -0500 OS Version: 10.6.2 (Build 10C540) Architecture: x86_64 Report Version: 6 Command: iTunes Path: /Applications/iTunes.app/Contents/MacOS/iTunes Version: 9.0.2 (9.0.2) Build Version: 2 Project Name: iTunes Source Version: 9022501 Parent: launchd [120] PID: 16878 Event: hang Duration: 3.55s (sampling started after 2 seconds) Steps: 16 (100ms sampling interval) Pageins: 5 Pageouts: 0 Process: iTunes [16878] Path: /Applications/iTunes.app/Contents/MacOS/iTunes UID: 501 Thread 8f96000 User stack: 16 ??? (in iTunes + 6633) [0x29e9] 16 ??? (in iTunes + 6843) [0x2abb] 16 ??? (in iTunes + 11734) [0x3dd6] 16 ??? (in iTunes + 44960) [0xbfa0] 16 ??? (in iTunes + 45327) [0xc10f] 16 ??? (in iTunes + 2295196) [0x23159c] 16 ??? (in iTunes + 103620) [0x1a4c4] 16 ??? (in iTunes + 105607) [0x1ac87] 16 ??? (in iTunes + 106442) [0x1afca] 16 OpenAComponent + 433 (in CarbonCore) [0x972e9dd0] 16 CallComponentOpen + 43 (in CarbonCore) [0x972ebae7] 16 CallComponentDispatch + 29 (in CarbonCore) [0x972ebb06] 16 DefaultOutputAUEntry + 319 (in CoreAudio) [0x70031117] 16 AUGenericOutputEntry + 15273 (in CoreAudio) [0x7000e960] 16 AUGenericOutputEntry + 13096 (in CoreAudio) [0x7000e0df] 16 AUGenericOutputEntry + 9628 (in CoreAudio) [0x7000d353] 16 ??? [0xe0c16d] 16 ??? [0xe0fdf8] 16 ??? [0xe0e1e7] 16 ahs_hermes_CoreAudio_init + 32 (in Instant Hijack Server) [0x13fc7e9] 16 semaphore_wait_signal_trap + 10 (in libSystem.B.dylib) [0x9798e922] Kernel stack: 16 semaphore_wait_continue + 0 [0x22a0a5] Thread 9b9eb7c User stack: 16 thread_start + 34 (in libSystem.B.dylib) [0x979bbe42] 16 _pthread_start + 345 (in libSystem.B.dylib) [0x979bbfbd] 16 ??? (in iTunes + 4011870) [0x3d475e] 16 CFRunLoopRun + 84 (in CoreFoundation) [0x993497a4] 16 CFRunLoopRunSpecific + 452 (in CoreFoundation) [0x99343864] 16 __CFRunLoopRun + 2079 (in CoreFoundation) [0x9934477f] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x9798e8da] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 9bc8b7c User stack: 16 start_wqthread + 30 (in libSystem.B.dylib) [0x979b4336] 16 _pthread_wqthread + 390 (in libSystem.B.dylib) [0x979b44f1] 16 _dispatch_worker_thread2 + 234 (in libSystem.B.dylib) [0x979b4a68] 16 _dispatch_queue_invoke + 163 (in libSystem.B.dylib) [0x979b4cc3] 16 kevent + 10 (in libSystem.B.dylib) [0x979b50ea] Kernel stack: 16 kevent + 97 [0x471745] Binary Images: 0x1000 - 0xbecfea com.apple.iTunes 9.0.2 (9.0.2) <1F665956-0131-39AF-F334-E29E510D42DA> /Applications/iTunes.app/Contents/MacOS/iTunes 0x13f6000 - 0x1402ff7 com.rogueamoeba.audio_hijack_server.hermes 2.2.2 (2.2.2) <9B29AE7F-6951-E63F-616A-482B62179A5C> /usr/local/hermes/modules/Instant Hijack Server.hermesmodule/Contents/MacOS/Instant Hijack Server 0x70000000 - 0x700cbffb com.apple.audio.units.Components 1.6.1 (1.6.1) <600769A2-479A-CA6E-A214-C8766F7CBD0F> /System/Library/Components/CoreAudio.component/Contents/MacOS/CoreAudio 0x97284000 - 0x975a3fe7 com.apple.CoreServices.CarbonCore 861.2 (861.2) <A9077470-3786-09F2-E0C7-F082B7F97838> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x9798e000 - 0x97b32feb libSystem.B.dylib ??? (???) <D45B91B2-2B4C-AAC0-8096-1FC48B7E9672> /usr/lib/libSystem.B.dylib 0x99308000 - 0x9947ffef com.apple.CoreFoundation 6.6.1 (550.13) <AE9FC6F7-F0B2-DE58-759E-7DB89C021A46> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation Process: AirPort Base Station Agent [142] Path: /System/Library/CoreServices/AirPort Base Station Agent.app/Contents/MacOS/AirPort Base Station Agent UID: 501 Thread 8b1d3d4 DispatchQueue 1 User stack: 16 ??? (in AirPort Base Station Agent + 5344) [0x1000014e0] 16 ??? (in AirPort Base Station Agent + 70666) [0x10001140a] 16 CFRunLoopRun + 70 (in CoreFoundation) [0x7fff86e859b6] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 8b80000 DispatchQueue 2 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 244 (in libSystem.B.dylib) [0x7fff87887286] 16 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff8788775c] 16 kevent + 10 (in libSystem.B.dylib) [0x7fff87885bba] Kernel stack: 16 kevent + 97 [0x471745] Thread 6e3c7a8 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 __workq_kernreturn + 10 (in libSystem.B.dylib) [0x7fff878869da] Kernel stack: 16 workqueue_thread_yielded + 562 [0x4cb6ae] Thread 8b0f3d4 User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 select$DARWIN_EXTSN + 10 (in libSystem.B.dylib) [0x7fff878b09e2] Kernel stack: 16 sleep + 52 [0x487f93] Thread 8bcb000 User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 ??? (in AirPort Base Station Agent + 71314) [0x100011692] 16 ??? (in AirPort Base Station Agent + 13712) [0x100003590] 16 ??? (in AirPort Base Station Agent + 71484) [0x10001173c] 16 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff878a79ee] Kernel stack: 16 semaphore_wait_continue + 0 [0x22a0a5] Binary Images: 0x100000000 - 0x100016fff com.apple.AirPortBaseStationAgent 1.5.4 (154.2) <73DF13C1-AF86-EC2C-9056-8D1946E607CF> /System/Library/CoreServices/AirPort Base Station Agent.app/Contents/MacOS/AirPort Base Station Agent 0x7fff86e3b000 - 0x7fff86faeff7 com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: AppleSpell [3041] Path: /System/Library/Services/AppleSpell.service/Contents/MacOS/AppleSpell UID: 501 Thread 999a000 DispatchQueue 1 User stack: 16 ??? (in AppleSpell + 5852) [0x1000016dc] 16 ??? (in AppleSpell + 6508) [0x10000196c] 16 -[NSSpellServer run] + 72 (in Foundation) [0x7fff81d3b796] 16 CFRunLoopRun + 70 (in CoreFoundation) [0x7fff86e859b6] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 8a9e7a8 DispatchQueue 2 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 244 (in libSystem.B.dylib) [0x7fff87887286] 16 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff8788775c] 16 kevent + 10 (in libSystem.B.dylib) [0x7fff87885bba] Kernel stack: 16 kevent + 97 [0x471745] Binary Images: 0x100000000 - 0x1000a9fef com.apple.AppleSpell 1.6.1 (61.1) <6DE57CC1-77A0-BC06-45E7-E1EACEBE1A88> /System/Library/Services/AppleSpell.service/Contents/MacOS/AppleSpell 0x7fff81cbc000 - 0x7fff81f3dfe7 com.apple.Foundation 6.6.1 (751.14) <767349DB-C486-70E8-7970-F13DB4CDAF37> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff86e3b000 - 0x7fff86faeff7 com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: autofsd [52] Path: /usr/libexec/autofsd UID: 0 Thread 79933d4 DispatchQueue 1 User stack: 16 ??? (in autofsd + 5340) [0x1000014dc] 16 ??? (in autofsd + 6461) [0x10000193d] 16 CFRunLoopRun + 70 (in CoreFoundation) [0x7fff86e859b6] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 75997a8 DispatchQueue 2 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 244 (in libSystem.B.dylib) [0x7fff87887286] 16 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff8788775c] 16 kevent + 10 (in libSystem.B.dylib) [0x7fff87885bba] Kernel stack: 16 kevent + 97 [0x471745] Binary Images: 0x100000000 - 0x100001ff7 autofsd ??? (???) <29276FAC-AEA8-1520-5329-C75F9D453D6C> /usr/libexec/autofsd 0x7fff86e3b000 - 0x7fff86faeff7 com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: blued [51] Path: /usr/sbin/blued UID: 0 Thread 7993000 DispatchQueue 1 User stack: 16 ??? (in blued + 5016) [0x100001398] 16 ??? (in blued + 152265) [0x1000252c9] 16 -[NSRunLoop(NSRunLoop) run] + 77 (in Foundation) [0x7fff81d07903] 16 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 270 (in Foundation) [0x7fff81d07a24] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 70db000 DispatchQueue 2 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 244 (in libSystem.B.dylib) [0x7fff87887286] 16 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff8788775c] 16 kevent + 10 (in libSystem.B.dylib) [0x7fff87885bba] Kernel stack: 16 kevent + 97 [0x471745] Thread 84d2000 User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 select$DARWIN_EXTSN + 10 (in libSystem.B.dylib) [0x7fff878b09e2] Kernel stack: 16 sleep + 52 [0x487f93] Binary Images: 0x100000000 - 0x100044fff blued ??? (???) <ECD752C9-F98E-3052-26BF-DC748281C992> /usr/sbin/blued 0x7fff81cbc000 - 0x7fff81f3dfe7 com.apple.Foundation 6.6.1 (751.14) <767349DB-C486-70E8-7970-F13DB4CDAF37> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff86e3b000 - 0x7fff86faeff7 com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: check_afp [84504] Path: /System/Library/Filesystems/AppleShare/check_afp.app/Contents/MacOS/check_afp UID: 0 Thread 1140f000 DispatchQueue 1 User stack: 16 ??? (in check_afp + 5596) [0x1000015dc] 16 ??? (in check_afp + 12976) [0x1000032b0] 16 ??? (in check_afp + 6664) [0x100001a08] 16 ??? (in check_afp + 6520) [0x100001978] 16 CFRunLoopRun + 70 (in CoreFoundation) [0x7fff86e859b6] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 13ad8b7c DispatchQueue 2 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 244 (in libSystem.B.dylib) [0x7fff87887286] 16 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff8788775c] 16 kevent + 10 (in libSystem.B.dylib) [0x7fff87885bba] Kernel stack: 16 kevent + 97 [0x471745] Thread 13ad6b7c User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 ??? (in check_afp + 13071) [0x10000330f] 16 mach_msg_server_once + 285 (in libSystem.B.dylib) [0x7fff878b2417] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 13ad87a8 User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 select$DARWIN_EXTSN + 10 (in libSystem.B.dylib) [0x7fff878b09e2] Kernel stack: 16 sleep + 52 [0x487f93] Binary Images: 0x100000000 - 0x100004ff7 com.apple.check_afp 2.0 (2.0) <EE865A7B-8CDC-7649-58E1-6FE2B43F7A73> /System/Library/Filesystems/AppleShare/check_afp.app/Contents/MacOS/check_afp 0x7fff86e3b000 - 0x7fff86faeff7 com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: configd [14] Path: /usr/libexec/configd UID: 0 Thread 704a3d4 DispatchQueue 1 User stack: 16 start + 52 (in configd) [0x100001488] 16 main + 2051 (in configd) [0x100001c9e] 16 server_loop + 72 (in configd) [0x1000024f4] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 6e70000 DispatchQueue 2 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 244 (in libSystem.B.dylib) [0x7fff87887286] 16 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff8788775c] 16 kevent + 10 (in libSystem.B.dylib) [0x7fff87885bba] Kernel stack: 16 kevent + 97 [0x471745] Thread 74a7b7c User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 plugin_exec + 1440 (in configd) [0x100003c5b] 16 CFRunLoopRun + 70 (in CoreFoundation) [0x7fff86e859b6] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 7560000 User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 _io_pm_force_active_settings + 2266 (in PowerManagement) [0x10050f968] 16 CFRunLoopRun + 70 (in CoreFoundation) [0x7fff86e859b6] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 75817a8 User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 select$DARWIN_EXTSN + 10 (in libSystem.B.dylib) [0x7fff878b09e2] Kernel stack: 16 sleep + 52 [0x487f93] Thread 8b1db7c User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 __workq_kernreturn + 10 (in libSystem.B.dylib) [0x7fff878869da] Kernel stack: 16 workqueue_thread_yielded + 562 [0x4cb6ae] Binary Images: 0x100000000 - 0x100026ff7 configd ??? (???) <58C02CBA-5556-4CDC-2763-814C4C7175DE> /usr/libexec/configd 0x10050c000 - 0x10051dfff com.apple.SystemConfiguration.PowerManagement 160.0.0 (160.0.0) <0AC3D2ED-919E-29C7-9EEF-629FBDDA6159> /System/Library/SystemConfiguration/PowerManagement.bundle/Contents/MacOS/PowerManagement 0x7fff86e3b000 - 0x7fff86faeff7 com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: coreaudiod [114] Path: /usr/sbin/coreaudiod UID: 202 Thread 83b93d4 DispatchQueue 1 User stack: 16 ??? (in coreaudiod + 3252) [0x100000cb4] 16 ??? (in coreaudiod + 26505) [0x100006789] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 847e3d4 DispatchQueue 2 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 244 (in libSystem.B.dylib) [0x7fff87887286] 16 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff8788775c] 16 kevent + 10 (in libSystem.B.dylib) [0x7fff87885bba] Kernel stack: 16 kevent + 97 [0x471745] Thread 854c000 User stack: 3 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 3 __workq_kernreturn + 10 (in libSystem.B.dylib) [0x7fff878869da] Kernel stack: 3 workqueue_thread_yielded + 562 [0x4cb6ae] Binary Images: 0x100000000 - 0x10001ffef coreaudiod ??? (???) <A060D20F-A6A7-A3AE-84EC-11D7D7DDEBC6> /usr/sbin/coreaudiod 0x7fff86e3b000 - 0x7fff86faeff7 com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: coreservicesd [66] Path: /System/Library/CoreServices/coreservicesd UID: 0 Thread 7994000 DispatchQueue 1 User stack: 16 ??? (in coreservicesd + 3756) [0x100000eac] 16 _CoreServicesServerMain + 522 (in CarbonCore) [0x7fff8327a972] 16 CFRunLoopRun + 70 (in CoreFoundation) [0x7fff86e859b6] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread 76227a8 User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 read + 10 (in libSystem.B.dylib) [0x7fff87877426] Kernel stack: 16 lo64_unix_scall + 77 [0x29e3fd] 16 unix_syscall64 + 617 [0x4ee947] 16 read_nocancel + 158 [0x496add] 16 write + 312 [0x49634d] 16 get_pathbuff + 3054 [0x3023db] 16 tsleep + 105 [0x4881ce] 16 wakeup + 786 [0x487da7] 16 thread_block + 33 [0x226fb5] 16 thread_block_reason + 331 [0x226f27] 16 thread_dispatch + 1950 [0x226c88] 16 machine_switch_context + 753 [0x2a5a37] Thread 7622b7c User stack: 16 thread_start + 13 (in libSystem.B.dylib) [0x7fff878a5e41] 16 _pthread_start + 331 (in libSystem.B.dylib) [0x7fff878a5f8e] 16 fmodWatchConsumer + 347 (in CarbonCore) [0x7fff8322f23f] 16 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff878a79ee] Kernel stack: 16 semaphore_wait_continue + 0 [0x22a0a5] Thread 79913d4 User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 244 (in libSystem.B.dylib) [0x7fff87887286] 16 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff8788775c] 16 kevent + 10 (in libSystem.B.dylib) [0x7fff87885bba] Kernel stack: 16 kevent + 97 [0x471745] Thread 84d2b7c User stack: 16 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 16 __workq_kernreturn + 10 (in libSystem.B.dylib) [0x7fff878869da] Kernel stack: 16 workqueue_thread_yielded + 562 [0x4cb6ae] Thread 9b643d4 User stack: 15 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 15 __workq_kernreturn + 10 (in libSystem.B.dylib) [0x7fff878869da] Kernel stack: 16 workqueue_thread_yielded + 562 [0x4cb6ae] Binary Images: 0x100000000 - 0x100000fff coreservicesd ??? (???) <D804E55B-4376-998C-AA25-2ADBFDD24414> /System/Library/CoreServices/coreservicesd 0x7fff831cb000 - 0x7fff834fdfef com.apple.CoreServices.CarbonCore 861.2 (861.2) <39F3B259-AC2A-792B-ECFE-4F3E72F2D1A5> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff86e3b000 - 0x7fff86faeff7 com.apple.CoreFoundation 6.6.1 (550.13) <1E952BD9-37C6-16BE-B2F0-CD92A6283D37> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: cron [31] Path: /usr/sbin/cron UID: 0 Thread 75acb7c DispatchQueue 1 User stack: 16 ??? (in cron + 2872) [0x100000b38] 16 ??? (in cron + 3991) [0x100000f97] 16 sleep + 61 (in libSystem.B.dylib) [0x7fff878f5090] 16 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff878a79ee] Kernel stack: 16 semaphore_wait_continue + 0 [0x22a0a5] Binary Images: 0x100000000 - 0x100006fff cron ??? (???) <3C5DCC7E-B6E8-1318-8E00-AB721270BFD4> /usr/sbin/cron 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: cvmsServ [104] Path: /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/cvmsServ UID: 0 Thread 761f3d4 DispatchQueue 1 User stack: 16 ??? (in cvmsServ + 4100) [0x100001004] 16 ??? (in cvmsServ + 23081) [0x100005a29] 16 mach_msg_server + 597 (in libSystem.B.dylib) [0x7fff878ea1c8] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Binary Images: 0x100000000 - 0x100008fff cvmsServ ??? (???) <6200AD80-4159-5656-8736-B72B7388C461> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/cvmsServ 0x7fff8786c000 - 0x7fff87a2aff7 libSystem.B.dylib ??? (???) <526DD3E5-2A8B-4512-ED97-01B832369959> /usr/lib/libSystem.B.dylib Process: DirectoryService [11] Path: /usr/sbin/DirectoryService UID: 0 Thread 70db7a8 DispatchQueue 1 User stack: 16 start + 52 (in DirectoryService) [0x10000da74] 16 main + 3086 (in DirectoryService) [0x10000e68a] 16 CFRunLoopRun + 70 (in CoreFoundation) [0x7fff86e859b6] 16 CFRunLoopRunSpecific + 575 (in CoreFoundation) [0x7fff86e85c2f] 16 __CFRunLoopRun + 1698 (in CoreFoundation) [0x7fff86e867a2] 16 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff8786ce3a] Kernel stack: 16 ipc_mqueue_receive_continue + 0 [0x210aa3] Thread <multiple> DispatchQueue 6 User stack: 17 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff87886a55] 17 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff87886bb8] 16 _dispatch_worker_thread2 + 231 (in libSystem.B.dylib) [0x7fff87887279] 16 _dispatch_call_block_and_release + 15 (in libSystem.B.dylib) [0x7fff878a8ce8] 16 syscall + 10 (in libSystem.B.dylib) [0x7fff878a92da] 1 _disp

    Read the article

  • Understanding G1 GC Logs

    - by poonam
    The purpose of this post is to explain the meaning of GC logs generated with some tracing and diagnostic options for G1 GC. We will take a look at the output generated with PrintGCDetails which is a product flag and provides the most detailed level of information. Along with that, we will also look at the output of two diagnostic flags that get enabled with -XX:+UnlockDiagnosticVMOptions option - G1PrintRegionLivenessInfo that prints the occupancy and the amount of space used by live objects in each region at the end of the marking cycle and G1PrintHeapRegions that provides detailed information on the heap regions being allocated and reclaimed. We will be looking at the logs generated with JDK 1.7.0_04 using these options. Option -XX:+PrintGCDetails Here's a sample log of G1 collection generated with PrintGCDetails. 0.522: [GC pause (young), 0.15877971 secs] [Parallel Time: 157.1 ms] [GC Worker Start (ms): 522.1 522.2 522.2 522.2 Avg: 522.2, Min: 522.1, Max: 522.2, Diff: 0.1] [Ext Root Scanning (ms): 1.6 1.5 1.6 1.9 Avg: 1.7, Min: 1.5, Max: 1.9, Diff: 0.4] [Update RS (ms): 38.7 38.8 50.6 37.3 Avg: 41.3, Min: 37.3, Max: 50.6, Diff: 13.3] [Processed Buffers : 2 2 3 2 Sum: 9, Avg: 2, Min: 2, Max: 3, Diff: 1] [Scan RS (ms): 9.9 9.7 0.0 9.7 Avg: 7.3, Min: 0.0, Max: 9.9, Diff: 9.9] [Object Copy (ms): 106.7 106.8 104.6 107.9 Avg: 106.5, Min: 104.6, Max: 107.9, Diff: 3.3] [Termination (ms): 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] [Termination Attempts : 1 4 4 6 Sum: 15, Avg: 3, Min: 1, Max: 6, Diff: 5] [GC Worker End (ms): 679.1 679.1 679.1 679.1 Avg: 679.1, Min: 679.1, Max: 679.1, Diff: 0.1] [GC Worker (ms): 156.9 157.0 156.9 156.9 Avg: 156.9, Min: 156.9, Max: 157.0, Diff: 0.1] [GC Worker Other (ms): 0.3 0.3 0.3 0.3 Avg: 0.3, Min: 0.3, Max: 0.3, Diff: 0.0] [Clear CT: 0.1 ms] [Other: 1.5 ms] [Choose CSet: 0.0 ms] [Ref Proc: 0.3 ms] [Ref Enq: 0.0 ms] [Free CSet: 0.3 ms] [Eden: 12M(12M)->0B(10M) Survivors: 0B->2048K Heap: 13M(64M)->9739K(64M)] [Times: user=0.59 sys=0.02, real=0.16 secs] This is the typical log of an Evacuation Pause (G1 collection) in which live objects are copied from one set of regions (young OR young+old) to another set. It is a stop-the-world activity and all the application threads are stopped at a safepoint during this time. This pause is made up of several sub-tasks indicated by the indentation in the log entries. Here's is the top most line that gets printed for the Evacuation Pause. 0.522: [GC pause (young), 0.15877971 secs] This is the highest level information telling us that it is an Evacuation Pause that started at 0.522 secs from the start of the process, in which all the regions being evacuated are Young i.e. Eden and Survivor regions. This collection took 0.15877971 secs to finish. Evacuation Pauses can be mixed as well. In which case the set of regions selected include all of the young regions as well as some old regions. 1.730: [GC pause (mixed), 0.32714353 secs] Let's take a look at all the sub-tasks performed in this Evacuation Pause. [Parallel Time: 157.1 ms] Parallel Time is the total elapsed time spent by all the parallel GC worker threads. The following lines correspond to the parallel tasks performed by these worker threads in this total parallel time, which in this case is 157.1 ms. [GC Worker Start (ms): 522.1 522.2 522.2 522.2Avg: 522.2, Min: 522.1, Max: 522.2, Diff: 0.1] The first line tells us the start time of each of the worker thread in milliseconds. The start times are ordered with respect to the worker thread ids – thread 0 started at 522.1ms and thread 1 started at 522.2ms from the start of the process. The second line tells the Avg, Min, Max and Diff of the start times of all of the worker threads. [Ext Root Scanning (ms): 1.6 1.5 1.6 1.9 Avg: 1.7, Min: 1.5, Max: 1.9, Diff: 0.4] This gives us the time spent by each worker thread scanning the roots (globals, registers, thread stacks and VM data structures). Here, thread 0 took 1.6ms to perform the root scanning task and thread 1 took 1.5 ms. The second line clearly shows the Avg, Min, Max and Diff of the times spent by all the worker threads. [Update RS (ms): 38.7 38.8 50.6 37.3 Avg: 41.3, Min: 37.3, Max: 50.6, Diff: 13.3] Update RS gives us the time each thread spent in updating the Remembered Sets. Remembered Sets are the data structures that keep track of the references that point into a heap region. Mutator threads keep changing the object graph and thus the references that point into a particular region. We keep track of these changes in buffers called Update Buffers. The Update RS sub-task processes the update buffers that were not able to be processed concurrently, and updates the corresponding remembered sets of all regions. [Processed Buffers : 2 2 3 2Sum: 9, Avg: 2, Min: 2, Max: 3, Diff: 1] This tells us the number of Update Buffers (mentioned above) processed by each worker thread. [Scan RS (ms): 9.9 9.7 0.0 9.7 Avg: 7.3, Min: 0.0, Max: 9.9, Diff: 9.9] These are the times each worker thread had spent in scanning the Remembered Sets. Remembered Set of a region contains cards that correspond to the references pointing into that region. This phase scans those cards looking for the references pointing into all the regions of the collection set. [Object Copy (ms): 106.7 106.8 104.6 107.9 Avg: 106.5, Min: 104.6, Max: 107.9, Diff: 3.3] These are the times spent by each worker thread copying live objects from the regions in the Collection Set to the other regions. [Termination (ms): 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] Termination time is the time spent by the worker thread offering to terminate. But before terminating, it checks the work queues of other threads and if there are still object references in other work queues, it tries to steal object references, and if it succeeds in stealing a reference, it processes that and offers to terminate again. [Termination Attempts : 1 4 4 6 Sum: 15, Avg: 3, Min: 1, Max: 6, Diff: 5] This gives the number of times each thread has offered to terminate. [GC Worker End (ms): 679.1 679.1 679.1 679.1 Avg: 679.1, Min: 679.1, Max: 679.1, Diff: 0.1] These are the times in milliseconds at which each worker thread stopped. [GC Worker (ms): 156.9 157.0 156.9 156.9 Avg: 156.9, Min: 156.9, Max: 157.0, Diff: 0.1] These are the total lifetimes of each worker thread. [GC Worker Other (ms): 0.3 0.3 0.3 0.3Avg: 0.3, Min: 0.3, Max: 0.3, Diff: 0.0] These are the times that each worker thread spent in performing some other tasks that we have not accounted above for the total Parallel Time. [Clear CT: 0.1 ms] This is the time spent in clearing the Card Table. This task is performed in serial mode. [Other: 1.5 ms] Time spent in the some other tasks listed below. The following sub-tasks (which individually may be parallelized) are performed serially. [Choose CSet: 0.0 ms] Time spent in selecting the regions for the Collection Set. [Ref Proc: 0.3 ms] Total time spent in processing Reference objects. [Ref Enq: 0.0 ms] Time spent in enqueuing references to the ReferenceQueues. [Free CSet: 0.3 ms] Time spent in freeing the collection set data structure. [Eden: 12M(12M)->0B(13M) Survivors: 0B->2048K Heap: 14M(64M)->9739K(64M)] This line gives the details on the heap size changes with the Evacuation Pause. This shows that Eden had the occupancy of 12M and its capacity was also 12M before the collection. After the collection, its occupancy got reduced to 0 since everything is evacuated/promoted from Eden during a collection, and its target size grew to 13M. The new Eden capacity of 13M is not reserved at this point. This value is the target size of the Eden. Regions are added to Eden as the demand is made and when the added regions reach to the target size, we start the next collection. Similarly, Survivors had the occupancy of 0 bytes and it grew to 2048K after the collection. The total heap occupancy and capacity was 14M and 64M receptively before the collection and it became 9739K and 64M after the collection. Apart from the evacuation pauses, G1 also performs concurrent-marking to build the live data information of regions. 1.416: [GC pause (young) (initial-mark), 0.62417980 secs] ….... 2.042: [GC concurrent-root-region-scan-start] 2.067: [GC concurrent-root-region-scan-end, 0.0251507] 2.068: [GC concurrent-mark-start] 3.198: [GC concurrent-mark-reset-for-overflow] 4.053: [GC concurrent-mark-end, 1.9849672 sec] 4.055: [GC remark 4.055: [GC ref-proc, 0.0000254 secs], 0.0030184 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 4.088: [GC cleanup 117M->106M(138M), 0.0015198 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 4.090: [GC concurrent-cleanup-start] 4.091: [GC concurrent-cleanup-end, 0.0002721] The first phase of a marking cycle is Initial Marking where all the objects directly reachable from the roots are marked and this phase is piggy-backed on a fully young Evacuation Pause. 2.042: [GC concurrent-root-region-scan-start] This marks the start of a concurrent phase that scans the set of root-regions which are directly reachable from the survivors of the initial marking phase. 2.067: [GC concurrent-root-region-scan-end, 0.0251507] End of the concurrent root region scan phase and it lasted for 0.0251507 seconds. 2.068: [GC concurrent-mark-start] Start of the concurrent marking at 2.068 secs from the start of the process. 3.198: [GC concurrent-mark-reset-for-overflow] This indicates that the global marking stack had became full and there was an overflow of the stack. Concurrent marking detected this overflow and had to reset the data structures to start the marking again. 4.053: [GC concurrent-mark-end, 1.9849672 sec] End of the concurrent marking phase and it lasted for 1.9849672 seconds. 4.055: [GC remark 4.055: [GC ref-proc, 0.0000254 secs], 0.0030184 secs] This corresponds to the remark phase which is a stop-the-world phase. It completes the left over marking work (SATB buffers processing) from the previous phase. In this case, this phase took 0.0030184 secs and out of which 0.0000254 secs were spent on Reference processing. 4.088: [GC cleanup 117M->106M(138M), 0.0015198 secs] Cleanup phase which is again a stop-the-world phase. It goes through the marking information of all the regions, computes the live data information of each region, resets the marking data structures and sorts the regions according to their gc-efficiency. In this example, the total heap size is 138M and after the live data counting it was found that the total live data size dropped down from 117M to 106M. 4.090: [GC concurrent-cleanup-start] This concurrent cleanup phase frees up the regions that were found to be empty (didn't contain any live data) during the previous stop-the-world phase. 4.091: [GC concurrent-cleanup-end, 0.0002721] Concurrent cleanup phase took 0.0002721 secs to free up the empty regions. Option -XX:G1PrintRegionLivenessInfo Now, let's look at the output generated with the flag G1PrintRegionLivenessInfo. This is a diagnostic option and gets enabled with -XX:+UnlockDiagnosticVMOptions. G1PrintRegionLivenessInfo prints the live data information of each region during the Cleanup phase of the concurrent-marking cycle. 26.896: [GC cleanup ### PHASE Post-Marking @ 26.896### HEAP committed: 0x02e00000-0x0fe00000 reserved: 0x02e00000-0x12e00000 region-size: 1048576 Cleanup phase of the concurrent-marking cycle started at 26.896 secs from the start of the process and this live data information is being printed after the marking phase. Committed G1 heap ranges from 0x02e00000 to 0x0fe00000 and the total G1 heap reserved by JVM is from 0x02e00000 to 0x12e00000. Each region in the G1 heap is of size 1048576 bytes. ### type address-range used prev-live next-live gc-eff### (bytes) (bytes) (bytes) (bytes/ms) This is the header of the output that tells us about the type of the region, address-range of the region, used space in the region, live bytes in the region with respect to the previous marking cycle, live bytes in the region with respect to the current marking cycle and the GC efficiency of that region. ### FREE 0x02e00000-0x02f00000 0 0 0 0.0 This is a Free region. ### OLD 0x02f00000-0x03000000 1048576 1038592 1038592 0.0 Old region with address-range from 0x02f00000 to 0x03000000. Total used space in the region is 1048576 bytes, live bytes as per the previous marking cycle are 1038592 and live bytes with respect to the current marking cycle are also 1038592. The GC efficiency has been computed as 0. ### EDEN 0x03400000-0x03500000 20992 20992 20992 0.0 This is an Eden region. ### HUMS 0x0ae00000-0x0af00000 1048576 1048576 1048576 0.0### HUMC 0x0af00000-0x0b000000 1048576 1048576 1048576 0.0### HUMC 0x0b000000-0x0b100000 1048576 1048576 1048576 0.0### HUMC 0x0b100000-0x0b200000 1048576 1048576 1048576 0.0### HUMC 0x0b200000-0x0b300000 1048576 1048576 1048576 0.0### HUMC 0x0b300000-0x0b400000 1048576 1048576 1048576 0.0### HUMC 0x0b400000-0x0b500000 1001480 1001480 1001480 0.0 These are the continuous set of regions called Humongous regions for storing a large object. HUMS (Humongous starts) marks the start of the set of humongous regions and HUMC (Humongous continues) tags the subsequent regions of the humongous regions set. ### SURV 0x09300000-0x09400000 16384 16384 16384 0.0 This is a Survivor region. ### SUMMARY capacity: 208.00 MB used: 150.16 MB / 72.19 % prev-live: 149.78 MB / 72.01 % next-live: 142.82 MB / 68.66 % At the end, a summary is printed listing the capacity, the used space and the change in the liveness after the completion of concurrent marking. In this case, G1 heap capacity is 208MB, total used space is 150.16MB which is 72.19% of the total heap size, live data in the previous marking was 149.78MB which was 72.01% of the total heap size and the live data as per the current marking is 142.82MB which is 68.66% of the total heap size. Option -XX:+G1PrintHeapRegions G1PrintHeapRegions option logs the regions related events when regions are committed, allocated into or are reclaimed. COMMIT/UNCOMMIT events G1HR COMMIT [0x6e900000,0x6ea00000]G1HR COMMIT [0x6ea00000,0x6eb00000] Here, the heap is being initialized or expanded and the region (with bottom: 0x6eb00000 and end: 0x6ec00000) is being freshly committed. COMMIT events are always generated in order i.e. the next COMMIT event will always be for the uncommitted region with the lowest address. G1HR UNCOMMIT [0x72700000,0x72800000]G1HR UNCOMMIT [0x72600000,0x72700000] Opposite to COMMIT. The heap got shrunk at the end of a Full GC and the regions are being uncommitted. Like COMMIT, UNCOMMIT events are also generated in order i.e. the next UNCOMMIT event will always be for the committed region with the highest address. GC Cycle events G1HR #StartGC 7G1HR CSET 0x6e900000G1HR REUSE 0x70500000G1HR ALLOC(Old) 0x6f800000G1HR RETIRE 0x6f800000 0x6f821b20G1HR #EndGC 7 This shows start and end of an Evacuation pause. This event is followed by a GC counter tracking both evacuation pauses and Full GCs. Here, this is the 7th GC since the start of the process. G1HR #StartFullGC 17G1HR UNCOMMIT [0x6ed00000,0x6ee00000]G1HR POST-COMPACTION(Old) 0x6e800000 0x6e854f58G1HR #EndFullGC 17 Shows start and end of a Full GC. This event is also followed by the same GC counter as above. This is the 17th GC since the start of the process. ALLOC events G1HR ALLOC(Eden) 0x6e800000 The region with bottom 0x6e800000 just started being used for allocation. In this case it is an Eden region and allocated into by a mutator thread. G1HR ALLOC(StartsH) 0x6ec00000 0x6ed00000G1HR ALLOC(ContinuesH) 0x6ed00000 0x6e000000 Regions being used for the allocation of Humongous object. The object spans over two regions. G1HR ALLOC(SingleH) 0x6f900000 0x6f9eb010 Single region being used for the allocation of Humongous object. G1HR COMMIT [0x6ee00000,0x6ef00000]G1HR COMMIT [0x6ef00000,0x6f000000]G1HR COMMIT [0x6f000000,0x6f100000]G1HR COMMIT [0x6f100000,0x6f200000]G1HR ALLOC(StartsH) 0x6ee00000 0x6ef00000G1HR ALLOC(ContinuesH) 0x6ef00000 0x6f000000G1HR ALLOC(ContinuesH) 0x6f000000 0x6f100000G1HR ALLOC(ContinuesH) 0x6f100000 0x6f102010 Here, Humongous object allocation request could not be satisfied by the free committed regions that existed in the heap, so the heap needed to be expanded. Thus new regions are committed and then allocated into for the Humongous object. G1HR ALLOC(Old) 0x6f800000 Old region started being used for allocation during GC. G1HR ALLOC(Survivor) 0x6fa00000 Region being used for copying old objects into during a GC. Note that Eden and Humongous ALLOC events are generated outside the GC boundaries and Old and Survivor ALLOC events are generated inside the GC boundaries. Other Events G1HR RETIRE 0x6e800000 0x6e87bd98 Retire and stop using the region having bottom 0x6e800000 and top 0x6e87bd98 for allocation. Note that most regions are full when they are retired and we omit those events to reduce the output volume. A region is retired when another region of the same type is allocated or we reach the start or end of a GC(depending on the region). So for Eden regions: For example: 1. ALLOC(Eden) Foo2. ALLOC(Eden) Bar3. StartGC At point 2, Foo has just been retired and it was full. At point 3, Bar was retired and it was full. If they were not full when they were retired, we will have a RETIRE event: 1. ALLOC(Eden) Foo2. RETIRE Foo top3. ALLOC(Eden) Bar4. StartGC G1HR CSET 0x6e900000 Region (bottom: 0x6e900000) is selected for the Collection Set. The region might have been selected for the collection set earlier (i.e. when it was allocated). However, we generate the CSET events for all regions in the CSet at the start of a GC to make sure there's no confusion about which regions are part of the CSet. G1HR POST-COMPACTION(Old) 0x6e800000 0x6e839858 POST-COMPACTION event is generated for each non-empty region in the heap after a full compaction. A full compaction moves objects around, so we don't know what the resulting shape of the heap is (which regions were written to, which were emptied, etc.). To deal with this, we generate a POST-COMPACTION event for each non-empty region with its type (old/humongous) and the heap boundaries. At this point we should only have Old and Humongous regions, as we have collapsed the young generation, so we should not have eden and survivors. POST-COMPACTION events are generated within the Full GC boundary. G1HR CLEANUP 0x6f400000G1HR CLEANUP 0x6f300000G1HR CLEANUP 0x6f200000 These regions were found empty after remark phase of Concurrent Marking and are reclaimed shortly afterwards. G1HR #StartGC 5G1HR CSET 0x6f400000G1HR CSET 0x6e900000G1HR REUSE 0x6f800000 At the end of a GC we retire the old region we are allocating into. Given that its not full, we will carry on allocating into it during the next GC. This is what REUSE means. In the above case 0x6f800000 should have been the last region with an ALLOC(Old) event during the previous GC and should have been retired before the end of the previous GC. G1HR ALLOC-FORCE(Eden) 0x6f800000 A specialization of ALLOC which indicates that we have reached the max desired number of the particular region type (in this case: Eden), but we decided to allocate one more. Currently it's only used for Eden regions when we extend the young generation because we cannot do a GC as the GC-Locker is active. G1HR EVAC-FAILURE 0x6f800000 During a GC, we have failed to evacuate an object from the given region as the heap is full and there is no space left to copy the object. This event is generated within GC boundaries and exactly once for each region from which we failed to evacuate objects. When Heap Regions are reclaimed ? It is also worth mentioning when the heap regions in the G1 heap are reclaimed. All regions that are in the CSet (the ones that appear in CSET events) are reclaimed at the end of a GC. The exception to that are regions with EVAC-FAILURE events. All regions with CLEANUP events are reclaimed. After a Full GC some regions get reclaimed (the ones from which we moved the objects out). But that is not shown explicitly, instead the non-empty regions that are left in the heap are printed out with the POST-COMPACTION events.

    Read the article

  • Inauguration Of My Laptop

    - by Pawan_Mishra
    Today I received my new laptop which is an Intel Core i5-2450M @ 2.50GHz 4 GB RAM machine . The other laptop(office provided) which I have used for past two years for programming is an Intel Core2 Duo T6570 @ 2.10GHz machine. Reason why I am talking about the laptops that I own is because of my interest in writing multi-threaded/parallel code using the new TPL API provided in the .Net 4.0 framework. I have spent significant amount of time in past one year writing code using the Parallel API of .Net...(read more)

    Read the article

  • Why does the instruction "do" require a "while"?

    - by 909 Niklas
    Since this statement is so common: while (true) (Java) or while (1) (C) or sometimes for (;;) Why is there not a single instruction for this? I could think that an instruction that could do it is just do but do requires a while at the end of the block but it would be more logical to write an infinite loop like this do { //loop forever } Why not? AFAIK the instruction do always requires a while at the end but if we could use it like above then it would be a clear way to define something like while (true) which I think should not be written like that (or for (;;)).

    Read the article

< Previous Page | 24 25 26 27 28 29 30 31 32 33 34 35  | Next Page >