Search Results

Search found 11197 results on 448 pages for 'handle leak'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 15/448 | < Previous Page | 11 12 13 14 15 16 17 18 19 20 21 22  | Next Page >

  • android database leak found IllegalStateException

    - by saravanan
    04-20 16:53:39.010: ERROR/Database(419): Leak found 04-20 16:53:39.010: ERROR/Database(419): java.lang.IllegalStateException: mPrograms size 1 04-20 16:53:39.010: ERROR/Database(419): at android.database.sqlite.SQLiteDatabase.finalize(SQLiteDatabase.java:1668) 04-20 16:53:39.010: ERROR/Database(419): at dalvik.system.NativeStart.run(Native Method) 04-20 16:53:39.010: ERROR/Database(419): Caused by: java.lang.IllegalStateException: /data/data/com.example.search/databases/rlite.db SQLiteDatabase created and never closed 04-20 16:53:39.010: ERROR/Database(419): at android.database.sqlite.SQLiteDatabase.(SQLiteDatabase.java:1694) 04-20 16:53:39.010: ERROR/Database(419): at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:738) 04-20 16:53:39.010: ERROR/Database(419): at android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:760) 04-20 16:53:39.010: ERROR/Database(419): at android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:753) 04-20 16:53:39.010: ERROR/Database(419): at android.app.ApplicationContext.openOrCreateDatabase(ApplicationContext.java:473) 04-20 16:53:39.010: ERROR/Database(419): at android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:193) 04-20 16:53:39.010: ERROR/Database(419): at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:98) 04-20 16:53:39.010: ERROR/Database(419): at com.example.search.Database.(Database.java:33) 04-20 16:53:39.010: ERROR/Database(419): at com.example.search.JobDetails.applyJob(JobDetails.java:120) 04-20 16:53:39.010: ERROR/Database(419): at com.example.search.JobDetails.jobdetailsAction(JobDetails.java:98) 04-20 16:53:39.010: ERROR/Database(419): at java.lang.reflect.Method.invokeNative(Native Method) 04-20 16:53:39.010: ERROR/Database(419): at java.lang.reflect.Method.invoke(Method.java:521) 04-20 16:53:39.010: ERROR/Database(419): at android.view.View$1.onClick(View.java:2026) 04-20 16:53:39.010: ERROR/Database(419): at android.view.View.performClick(View.java:2364) 04-20 16:53:39.010: ERROR/Database(419): at android.view.View.onTouchEvent(View.java:4179) 04-20 16:53:39.010: ERROR/Database(419): at android.widget.TextView.onTouchEvent(TextView.java:6540) 04-20 16:53:39.010: ERROR/Database(419): at android.view.View.dispatchTouchEvent(View.java:3709) 04-20 16:53:39.010: ERROR/Database(419): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884) 04-20 16:53:39.010: ERROR/Database(419): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884) 04-20 16:53:39.010: ERROR/Database(419): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884) 04-20 16:53:39.010: ERROR/Database(419): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884) 04-20 16:53:39.010: ERROR/Database(419): at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:884) 04-20 16:53:39.010: ERROR/Database(419): at com.android.internal.policy.impl.PhoneWindow$DecorView.superDispatchTouchEvent(PhoneWindow.java:1659) 04-20 16:53:39.010: ERROR/Database(419): at com.android.internal.policy.impl.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:1107) 04-20 16:53:39.010: ERROR/Database(419): at android.app.Activity.dispatchTouchEvent(Activity.java:2061) 04-20 16:53:39.010: ERROR/Database(419): at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchTouchEvent(PhoneWindow.java:1643) 04-20 16:53:39.010: ERROR/Database(419): at android.view.ViewRoot.handleMessage(ViewRoot.java:1691) 04-20 16:53:39.010: ERROR/Database(419): at android.os.Handler.dispatchMessage(Handler.java:99) 04-20 16:53:39.010: ERROR/Database(419): at android.os.Looper.loop(Looper.java:123) 04-20 16:53:39.010: ERROR/Database(419): at android.app.ActivityThread.main(ActivityThread.java:4363) 04-20 16:53:39.010: ERROR/Database(419): at java.lang.reflect.Method.invokeNative(Native Method) 04-20 16:53:39.010: ERROR/Database(419): at java.lang.reflect.Method.invoke(Method.java:521) 04-20 16:53:39.010: ERROR/Database(419): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860) 04-20 16:53:39.010: ERROR/Database(419): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) 04-20 16:53:39.010: ERROR/Database(419): at dalvik.system.NativeStart.main(Native Method) when i read the database show error like this. please do reply me

    Read the article

  • How to find that Mutex in C# is acquired?

    - by TN
    How can I find from mutex handle in C# that a mutex is acquired? When mutex.WaitOne(timeout) timeouts, it returns false. However, how can I find that from the mutex handle? (Maybe using p/invoke.) UPDATE: public class InterProcessLock : IDisposable { readonly Mutex mutex; public bool IsAcquired { get; private set; } public InterProcessLock(string name, TimeSpan timeout) { bool created; var security = new MutexSecurity(); security.AddAccessRule(new MutexAccessRule(new SecurityIdentifier(WellKnownSidType.WorldSid, null), MutexRights.Synchronize | MutexRights.Modify, AccessControlType.Allow)); mutex = new Mutex(false, name, out created, security); IsAcquired = mutex.WaitOne(timeout); } #region IDisposable Members public void Dispose() { if (IsAcquired) mutex.ReleaseMutex(); } #endregion } Currently, I am using my own property IsAcquired to determine whether I should release a mutex. Not essential but clearer, would be not to use a secondary copy of the information represented by IsAcquired property, but rather to ask directly the mutex whether it is acquired by me. Since calling mutex.ReleaseMutex() throws an exception if it is not acquired by me. (By acquired state I mean that the mutex is in not-signaled state when I am owning the mutex.)

    Read the article

  • calling calloc - memory leak valgrind

    - by Mike
    The following code is an example from the NCURSES menu library. I'm not sure what could be wrong with the code, but valgrind reports some problems. Any ideas... ==4803== 1,049 (72 direct, 977 indirect) bytes in 1 blocks are definitely lost in loss record 25 of 36 ==4803== at 0x4C24477: calloc (vg_replace_malloc.c:418) ==4803== by 0x400E93: main (in /home/gerardoj/a.out) ==4803== ==4803== LEAK SUMMARY: ==4803== definitely lost: 72 bytes in 1 blocks ==4803== indirectly lost: 977 bytes in 10 blocks ==4803== possibly lost: 0 bytes in 0 blocks ==4803== still reachable: 64,942 bytes in 262 blocks Source code: #include <curses.h> #include <menu.h> #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0])) #define CTRLD 4 char *choices[] = { "Choice 1", "Choice 2", "Choice 3", "Choice 4", "Choice 5", "Choice 6", "Choice 7", "Exit", } ; int main() { ITEM **my_items; int c; MENU *my_menu; int n_choices, i; ITEM *cur_item; /* Initialize curses */ initscr(); cbreak(); noecho(); keypad(stdscr, TRUE); /* Initialize items */ n_choices = ARRAY_SIZE(choices); my_items = (ITEM **)calloc(n_choices + 1, sizeof(ITEM *)); for (i = 0; i < n_choices; ++i) { my_items[i] = new_item(choices[i], choices[i]); } my_items[n_choices] = (ITEM *)NULL; my_menu = new_menu((ITEM **)my_items); /* Make the menu multi valued */ menu_opts_off(my_menu, O_ONEVALUE); mvprintw(LINES - 3, 0, "Use <SPACE> to select or unselect an item."); mvprintw(LINES - 2, 0, "<ENTER> to see presently selected items(F1 to Exit)"); post_menu(my_menu); refresh(); while ((c = getch()) != KEY_F(1)) { switch (c) { case KEY_DOWN: menu_driver(my_menu, REQ_DOWN_ITEM); break; case KEY_UP: menu_driver(my_menu, REQ_UP_ITEM); break; case ' ': menu_driver(my_menu, REQ_TOGGLE_ITEM); break; case 10: { char temp[200]; ITEM **items; items = menu_items(my_menu); temp[0] = '\0'; for (i = 0; i < item_count(my_menu); ++i) if(item_value(items[i]) == TRUE) { strcat(temp, item_name(items[i])); strcat(temp, " "); } move(20, 0); clrtoeol(); mvprintw(20, 0, temp); refresh(); } break; } } free_item(my_items[0]); free_item(my_items[1]); free_menu(my_menu); endwin(); }

    Read the article

  • Possible memory leak problem

    - by MaiTiano
    I write two pieces of c programs like following, during memcheck process using Valgrind, a lot of mem leak information is given. int GetMemory(int framewidth, int frameheight, int SR/*, int blocksize*//*,int ALL_REF_NUM*/) { //int i,j; int memory_size = 0; //int refnum = ALL_REF_NUM; int input_search_range = SR; memory_size += get_mem2D(&curFrameY, frameheight, framewidth); memory_size += get_mem2D(&curFrameU, frameheight>>1, framewidth>>1); memory_size += get_mem2D(&curFrameV, frameheight>>1, framewidth>>1); memory_size += get_mem3D(&prevFrameY, refnum, frameheight, framewidth);// to allocate reference frame buffer accoding to the reference frame number memory_size += get_mem3D(&prevFrameU, refnum, frameheight>>1, framewidth>>1); memory_size += get_mem3D(&prevFrameV, refnum, frameheight>>1, framewidth>>1); memory_size += get_mem2D(&mpFrameY, frameheight, framewidth); memory_size += get_mem2D(&mpFrameU, frameheight>>1, framewidth>>1); memory_size += get_mem2D(&mpFrameV, frameheight>>1, framewidth>>1); memory_size += get_mem2D(&searchwindow, input_search_range*2 + blocksize, input_search_range*2 + blocksize);// to allocate search window according to the searchrange /*memory_size +=*/ get_mem1D(/*&SAD_cost, height, width*/); // memory_size += get_mem2D(&searchwindow, 80, 80);// if searchrange is 32, then only 32+1+32+15 pixels is needed in each row and col, therefore the range of // search window is enough to be set to 80 ! memory_size += get_mem2Dint(&all_mv, height/blocksize, width/blocksize); return 0; } void FreeMemory(int refno) { free_mem2D(curFrameY); free_mem2D(curFrameU); free_mem2D(curFrameV); free_mem3D(prevFrameY,refno); free_mem3D(prevFrameU,refno); free_mem3D(prevFrameV,refno); free_mem2D(mpFrameY); free_mem2D(mpFrameU); free_mem2D(mpFrameV); free_mem2D(searchwindow); free_mem1D(); free_mem2Dint(all_mv); } void free_mem1D() { free(SAD_cost); } Now I hope to make sure where are the possible problems in my program? Here I may post some valgrind information to let you know about the actual error information. ==29105== by 0x804A906: main (me_search.c:1480) ==29105== ==29105== ==29105== HEAP SUMMARY: ==29105== in use at exit: 124,088 bytes in 18 blocks ==29105== total heap usage: 37 allocs, 21 frees, 749,276 bytes allocated ==29105== ==29105== 272 bytes in 1 blocks are still reachable in loss record 1 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x804885E: GetMemory (me_search.c:117) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 352 bytes in 1 blocks are still reachable in loss record 2 of 18 ==29105== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==29105== by 0x409537E: __fopen_internal (iofopen.c:76) ==29105== by 0x409544B: fopen@@GLIBC_2.1 (iofopen.c:107) ==29105== by 0x804A660: main (me_search.c:1439) ==29105== ==29105== 584 bytes in 1 blocks are still reachable in loss record 3 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x8048724: GetMemory (me_search.c:106) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 584 bytes in 1 blocks are still reachable in loss record 4 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x8048747: GetMemory (me_search.c:107) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 584 bytes in 1 blocks are still reachable in loss record 5 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x8048809: GetMemory (me_search.c:114) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 584 bytes in 1 blocks are still reachable in loss record 6 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x804882C: GetMemory (me_search.c:115) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 584 bytes in 1 blocks are definitely lost in loss record 7 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x804A4F8: get_mem3D (me_search.c:1393) ==29105== by 0x804879B: GetMemory (me_search.c:110) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 584 bytes in 1 blocks are definitely lost in loss record 8 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x804A4F8: get_mem3D (me_search.c:1393) ==29105== by 0x80487C9: GetMemory (me_search.c:111) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 1,168 bytes in 1 blocks are still reachable in loss record 9 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x8048701: GetMemory (me_search.c:105) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 1,168 bytes in 1 blocks are still reachable in loss record 10 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x80487E6: GetMemory (me_search.c:113) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 1,168 bytes in 1 blocks are definitely lost in loss record 11 of 18 ==29105== at 0x402425F: calloc (vg_replace_malloc.c:467) ==29105== by 0x804A296: get_mem2D (me_search.c:1315) ==29105== by 0x804A4F8: get_mem3D (me_search.c:1393) ==29105== by 0x804876D: GetMemory (me_search.c:109) ==29105== by 0x804A757: main (me_search.c:1456) ==29105== ==29105== 6,336 bytes in 1 blocks are definitely lost in loss record 12 of 18 ==29105== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==29105== by 0x804A25C: get_mem1D (me_search.c:1295) ==29105== by 0x8048866: GetMemory (me_search.c:119) ==29105== by 0x804A757: main (me_search.c:1456)

    Read the article

  • Memory leak in C++ program.

    - by lampshade
    What I have is a very crude linked list..THe problem for me is that I am getting a memory leak in the constructor or main. I think it is the constructor. I have not yet deleted the eventName varaible that I have allocated memory for. Could someone help please? :/ (This is not a homework question) class Event { private: char * eventName ; string userEvent; struct node { node(); node * nextByName; const char * eventName; }; node * headByName; public: Event(const char * eventName, const Date &myDate); Event(); virtual ~Event(); void insert(const char * eventName, const Date &myDate, const Time &myTime); void setEvent(); const char * const getEvent() const { return userEvent.c_str(); }; void displayByName(ostream& out) const; }; Event::Event(const char * eventName, const Date &myDate) : eventName(new char[strlen(eventName)+1]), headByName(NULL), userEvent("") { if (eventName) { size_t length = strlen(eventName) +1; strcpy_s(this->eventName, length, eventName); } else eventName = NULL; } Event::Event() : eventName(NULL), userEvent(NULL), headByName(NULL) { } Event::~Event() { node * temp_node = NULL; node * current_node = headByName; while ( current_node ) { temp_node = current_node->nextByName; delete current_node; current_node = temp_node; } } void Event::insert(const char * eventName, const Date &myDate, const Time &myTime) // when we insert we dont care about the time, just the name and the date { node * current_node = new node(); if ( headByName == NULL ) { headByName = current_node; headByName->eventName = eventName; } else { node * search_node = headByName; node * prev_node = NULL; while ( search_node != NULL ) { prev_node = search_node; search_node = search_node->nextByName; } if ( NULL == prev_node ) { headByName = current_node; } else { prev_node->nextByName = current_node; } current_node->nextByName = search_node; current_node->eventName = eventName ; } } void Event::displayByName(ostream& out) const { cout << "Scheduled Events are: " << endl << endl; node * current_node = headByName; while ( current_node ) { (char*)eventName = (char*)current_node->eventName; out << eventName << endl; current_node = current_node->nextByName; } } Event::node::node() : nextByName(NULL), eventName(NULL) { } void Event::setEvent() { cout << "\n\nEnter a new event! "; cin.getline((char*)userEvent.c_str(), 256); size_t length = strlen(userEvent.c_str()) +1; strcpy_s((char*)this->userEvent.c_str(), length, userEvent.c_str()); } /********************************************************************************* **********************************************************************************/ int main() { Date * dPtr = new Date("March", 21, 2010); // instaintiate our Date class object by allocating default date paramateres. Event * ePtr = new Event("First Day of Spring", *dPtr); Time * tPtr = new Time(10,12,"PM"); cout << "default Time is: " << tPtr << endl; cout << "default Date is: " << dPtr << endl; ePtr->insert("First Day of Spring",*dPtr, *tPtr); ePtr->insert("Valentines Day", Date("February",14,2010), *tPtr); ePtr->insert("New Years Day", Date("Janurary",1,2011), *tPtr); ePtr->insert("St. Patricks Day", Date("March",17,2010), *tPtr); ePtr->displayByName(cout); ePtr->setEvent(); const char * const theEvent = ePtr->getEvent(); dPtr->setDate(); ePtr->insert(theEvent, *dPtr, *tPtr); tPtr->setTime(); cout << "Your event: " << theEvent << " is scheduled for: " << endl << dPtr << "at" << tPtr; ePtr->displayByName(cout); delete tPtr; delete dPtr; delete ePtr; cin.ignore(); return 0; }

    Read the article

  • Memory leak when using Workflow 4.0 SqlWorkflowInstanceStore and PersistableIdleAction.Unload

    - by Rohland
    Hi, This particular problem is driving me nuts. I wonder if anyone has experienced a similar problem. If I load up a workflow then unload it and perform a memory snapshot then the result is predictable - my workflow is no longer in memory. However, if I load up a workflow and set the PersistableIdle action to PersistableIdleAction.Unload and let the workflow idle the workflow remains in memory even though the Unload action fires. I used ANTS Memory Profiler to debug this issue. This is the object retention graph outputted showing that an internal object is hanging onto my workflow instance. Can anyone else verify this problem? My code amounts to the following: Create SqlWorkflowInstanceStore and setup lock owner handle -- At this point I take a memory snapshot Create an instance of Workflow1 Set the PersistableIdle action Apply the instancestore to Workflow1 Setup action event handlers for Idle, Unload, UnhandledException etc. Persist the workflow instance Run the workflow instance Wait for instance to idle (caused by Delay activity) Ensure the Unload action is fired -- At this point I take a second memory snapshot From the above image, it is clear that the only object referencing Workflow1 is some internal event handlers result which I have no ability to dispose of. Any clues?

    Read the article

  • When constructing a Bitmap with Bitmap.FromHbitmap(), how soon can the original bitmap handle be del

    - by GBegen
    From the documentation of Image.FromHbitmap() at http://msdn.microsoft.com/en-us/library/k061we7x%28VS.80%29.aspx : The FromHbitmap method makes a copy of the GDI bitmap; so you can release the incoming GDI bitmap using the GDIDeleteObject method immediately after creating the new Image. This pretty explicitly states that the bitmap handle can be immediately deleted with DeleteObject as soon as the Bitmap instance is created. Looking at the implementation of Image.FromHbitmap() with Reflector, however, shows that it is a pretty thin wrapper around the GDI+ function, GdipCreateBitmapFromHBITMAP(). There is pretty scant documentation on the GDI+ flat functions, but http://msdn.microsoft.com/en-us/library/ms533971%28VS.85%29.aspx says that GdipCreateBitmapFromHBITMAP() corresponds to the Bitmap::Bitmap() constructor that takes an HBITMAP and an HPALETTE as parameters. The documentation for this version of the Bitmap::Bitmap() constructor at http://msdn.microsoft.com/en-us/library/ms536314%28VS.85%29.aspx has this to say: You are responsible for deleting the GDI bitmap and the GDI palette. However, you should not delete the GDI bitmap or the GDI palette until after the GDI+ Bitmap::Bitmap object is deleted or goes out of scope. Do not pass to the GDI+ Bitmap::Bitmap constructor a GDI bitmap or a GDI palette that is currently (or was previously) selected into a device context. Furthermore, one can see the source code for the C++ portion of GDI+ in GdiPlusBitmap.h that the Bitmap::Bitmap() constructor in question is itself a wrapper for the GdipCreateBitmapFromHBITMAP() function from the flat API: inline Bitmap::Bitmap( IN HBITMAP hbm, IN HPALETTE hpal ) { GpBitmap *bitmap = NULL; lastResult = DllExports::GdipCreateBitmapFromHBITMAP(hbm, hpal, &bitmap); SetNativeImage(bitmap); } What I can't easily see is the implementation of GdipCreateBitmapFromHBITMAP() that is the core of this functionality, but the two remarks in the documentation seem to be contradictory. The .Net documentation says I can delete the bitmap handle immediately, and the GDI+ documentation says the bitmap handle must be kept until the wrapping object is deleted, but both are based on the same GDI+ function. Furthermore, the GDI+ documentation warns against using a source HBITMAP that is currently or previously selected into a device context. While I can understand why the bitmap should not be selected into a device context currently, I do not understand why there is a warning against using a bitmap that was previously selected into a device context. That would seem to prevent use of GDI+ bitmaps that had been created in memory using standard GDI. So, in summary: Does the original bitmap handle need to be kept around until the .Net Bitmap object is disposed? Does the GDI+ function, GdipCreateBitmapFromHBITMAP(), make a copy of the source bitmap or merely hold onto the handle to the original? Why should I not use an HBITMAP that was previously selected into a device context?

    Read the article

  • Memory leak / GLib issue.

    - by Andrei Ciobanu
    1: /* 2: * File: xyn-playlist.c 3: * Author: Andrei Ciobanu 4: * 5: * Created on June 4, 2010, 12:47 PM 6: */ 7:   8: #include <dirent.h> 9: #include <glib.h> 10: #include <stdio.h> 11: #include <stdlib.h> 12: #include <sys/stat.h> 13: #include <unistd.h> 14:   15: /** 16: * Returns a list all the file(paths) from a directory. 17: * Returns 'NULL' if a certain error occurs. 18: * @param dir_path. 19: * @param A list of gchars* indicating what file patterns to detect. 20: */ 21: GSList *xyn_pl_get_files(const gchar *dir_path, GSList *file_patterns) { 22: /* Returning list containing file paths */ 23: GSList *fpaths = NULL; 24: /* Used to scan directories for subdirs. Acts like a 25: * stack, to avoid recursion. */ 26: GSList *dirs = NULL; 27: /* Current dir */ 28: DIR *cdir = NULL; 29: /* Current dir entries */ 30: struct dirent *cent = NULL; 31: /* File stats */ 32: struct stat cent_stat; 33: /* dir_path duplicate, on the heap */ 34: gchar *dir_pdup; 35:   36: if (dir_path == NULL) { 37: return NULL; 38: } 39:   40: dir_pdup = g_strdup((const gchar*) dir_path); 41: dirs = g_slist_append(dirs, (gpointer) dir_pdup); 42: while (dirs != NULL) { 43: cdir = opendir((const gchar*) dirs->data); 44: if (cdir == NULL) { 45: g_slist_free(dirs); 46: g_slist_free(fpaths); 47: return NULL; 48: } 49: chdir((const gchar*) dirs->data); 50: while ((cent = readdir(cdir)) != NULL) { 51: lstat(cent->d_name, &cent_stat); 52: if (S_ISDIR(cent_stat.st_mode)) { 53: if (g_strcmp0(cent->d_name, ".") == 0 || 54: g_strcmp0(cent->d_name, "..") == 0) { 55: /* Skip "." and ".." dirs */ 56: continue; 57: } 58: dirs = g_slist_append(dirs, 59: g_strconcat((gchar*) dirs->data, "/", cent->d_name, NULL)); 60: } else { 61: fpaths = g_slist_append(fpaths, 62: g_strconcat((gchar*) dirs->data, "/", cent->d_name, NULL)); 63: } 64: } 65: g_free(dirs->data); 66: dirs = g_slist_delete_link(dirs, dirs); 67: closedir(cdir); 68: } 69: return fpaths; 70: } 71:   72: int main(int argc, char** argv) { 73: GSList *l = NULL; 74: l = xyn_pl_get_files("/home/andrei/Music", NULL); 75: g_slist_foreach(l,(GFunc)printf,NULL); 76: printf("%d\n",g_slist_length(l)); 77: g_slist_free(l); 78: return (0); 79: } 80:   81:   82: -----------------------------------------------------------------------------------------------==15429== 83: ==15429== HEAP SUMMARY: 84: ==15429== in use at exit: 751,451 bytes in 7,263 blocks 85: ==15429== total heap usage: 8,611 allocs, 1,348 frees, 22,898,217 bytes allocated 86: ==15429== 87: ==15429== 120 bytes in 1 blocks are possibly lost in loss record 1 of 11 88: ==15429== at 0x4024106: memalign (vg_replace_malloc.c:581) 89: ==15429== by 0x4024163: posix_memalign (vg_replace_malloc.c:709) 90: ==15429== by 0x40969C1: ??? (in /lib/libglib-2.0.so.0.2400.1) 91: ==15429== by 0x40971F6: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 92: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 93: ==15429== by 0x80488F0: xyn_pl_get_files (xyn-playlist.c:41) 94: ==15429== by 0x8048848: main (main.c:18) 95: ==15429== 96: ==15429== 129 bytes in 1 blocks are possibly lost in loss record 2 of 11 97: ==15429== at 0x4024F20: malloc (vg_replace_malloc.c:236) 98: ==15429== by 0x4081243: g_malloc (in /lib/libglib-2.0.so.0.2400.1) 99: ==15429== by 0x409B85B: g_strconcat (in /lib/libglib-2.0.so.0.2400.1) 100: ==15429== by 0x80489FE: xyn_pl_get_files (xyn-playlist.c:62) 101: ==15429== by 0x8048848: main (main.c:18) 102: ==15429== 103: ==15429== 360 bytes in 3 blocks are possibly lost in loss record 3 of 11 104: ==15429== at 0x4024106: memalign (vg_replace_malloc.c:581) 105: ==15429== by 0x4024163: posix_memalign (vg_replace_malloc.c:709) 106: ==15429== by 0x40969C1: ??? (in /lib/libglib-2.0.so.0.2400.1) 107: ==15429== by 0x4097222: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 108: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 109: ==15429== by 0x80488F0: xyn_pl_get_files (xyn-playlist.c:41) 110: ==15429== by 0x8048848: main (main.c:18) 111: ==15429== 112: ==15429== 508 bytes in 1 blocks are still reachable in loss record 4 of 11 113: ==15429== at 0x402425F: calloc (vg_replace_malloc.c:467) 114: ==15429== by 0x408113B: g_malloc0 (in /lib/libglib-2.0.so.0.2400.1) 115: ==15429== by 0x409624D: ??? (in /lib/libglib-2.0.so.0.2400.1) 116: ==15429== by 0x409710C: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 117: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 118: ==15429== by 0x80488F0: xyn_pl_get_files (xyn-playlist.c:41) 119: ==15429== by 0x8048848: main (main.c:18) 120: ==15429== 121: ==15429== 508 bytes in 1 blocks are still reachable in loss record 5 of 11 122: ==15429== at 0x402425F: calloc (vg_replace_malloc.c:467) 123: ==15429== by 0x408113B: g_malloc0 (in /lib/libglib-2.0.so.0.2400.1) 124: ==15429== by 0x409626F: ??? (in /lib/libglib-2.0.so.0.2400.1) 125: ==15429== by 0x409710C: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 126: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 127: ==15429== by 0x80488F0: xyn_pl_get_files (xyn-playlist.c:41) 128: ==15429== by 0x8048848: main (main.c:18) 129: ==15429== 130: ==15429== 508 bytes in 1 blocks are still reachable in loss record 6 of 11 131: ==15429== at 0x402425F: calloc (vg_replace_malloc.c:467) 132: ==15429== by 0x408113B: g_malloc0 (in /lib/libglib-2.0.so.0.2400.1) 133: ==15429== by 0x4096291: ??? (in /lib/libglib-2.0.so.0.2400.1) 134: ==15429== by 0x409710C: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 135: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 136: ==15429== by 0x80488F0: xyn_pl_get_files (xyn-playlist.c:41) 137: ==15429== by 0x8048848: main (main.c:18) 138: ==15429== 139: ==15429== 1,200 bytes in 10 blocks are possibly lost in loss record 7 of 11 140: ==15429== at 0x4024106: memalign (vg_replace_malloc.c:581) 141: ==15429== by 0x4024163: posix_memalign (vg_replace_malloc.c:709) 142: ==15429== by 0x40969C1: ??? (in /lib/libglib-2.0.so.0.2400.1) 143: ==15429== by 0x40971F6: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 144: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 145: ==15429== by 0x8048A0D: xyn_pl_get_files (xyn-playlist.c:61) 146: ==15429== by 0x8048848: main (main.c:18) 147: ==15429== 148: ==15429== 2,040 bytes in 1 blocks are still reachable in loss record 8 of 11 149: ==15429== at 0x402425F: calloc (vg_replace_malloc.c:467) 150: ==15429== by 0x408113B: g_malloc0 (in /lib/libglib-2.0.so.0.2400.1) 151: ==15429== by 0x40970AB: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 152: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 153: ==15429== by 0x80488F0: xyn_pl_get_files (xyn-playlist.c:41) 154: ==15429== by 0x8048848: main (main.c:18) 155: ==15429== 156: ==15429== 4,320 bytes in 36 blocks are possibly lost in loss record 9 of 11 157: ==15429== at 0x4024106: memalign (vg_replace_malloc.c:581) 158: ==15429== by 0x4024163: posix_memalign (vg_replace_malloc.c:709) 159: ==15429== by 0x40969C1: ??? (in /lib/libglib-2.0.so.0.2400.1) 160: ==15429== by 0x4097222: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 161: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 162: ==15429== by 0x80489D2: xyn_pl_get_files (xyn-playlist.c:58) 163: ==15429== by 0x8048848: main (main.c:18) 164: ==15429== 165: ==15429== 56,640 bytes in 472 blocks are possibly lost in loss record 10 of 11 166: ==15429== at 0x4024106: memalign (vg_replace_malloc.c:581) 167: ==15429== by 0x4024163: posix_memalign (vg_replace_malloc.c:709) 168: ==15429== by 0x40969C1: ??? (in /lib/libglib-2.0.so.0.2400.1) 169: ==15429== by 0x4097222: g_slice_alloc (in /lib/libglib-2.0.so.0.2400.1) 170: ==15429== by 0x40988A5: g_slist_append (in /lib/libglib-2.0.so.0.2400.1) 171: ==15429== by 0x8048A0D: xyn_pl_get_files (xyn-playlist.c:61) 172: ==15429== by 0x8048848: main (main.c:18) 173: ==15429== 174: ==15429== 685,118 bytes in 6,736 blocks are definitely lost in loss record 11 of 11 175: ==15429== at 0x4024F20: malloc (vg_replace_malloc.c:236) 176: ==15429== by 0x4081243: g_malloc (in /lib/libglib-2.0.so.0.2400.1) 177: ==15429== by 0x409B85B: g_strconcat (in /lib/libglib-2.0.so.0.2400.1) 178: ==15429== by 0x80489FE: xyn_pl_get_files (xyn-playlist.c:62) 179: ==15429== by 0x8048848: main (main.c:18) 180: ==15429== 181: ==15429== LEAK SUMMARY: 182: ==15429== definitely lost: 685,118 bytes in 6,736 blocks 183: ==15429== indirectly lost: 0 bytes in 0 blocks 184: ==15429== possibly lost: 62,769 bytes in 523 blocks 185: ==15429== still reachable: 3,564 bytes in 4 blocks 186: ==15429== suppressed: 0 bytes in 0 blocks 187: ==15429== 188: ==15429== For counts of detected and suppressed errors, rerun with: -v 189: ==15429== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 17 from 8) 190: ---------------------------------------------------------------------------------------------- I am using the above code in order to create a list with all the filepaths in a certain directory. (In my case fts.h or ftw.h are not an option). I am using GLib as the data structures library. Still I have my doubts in regarding the way GLib is allocating, de-allocating memory ? When invoking g_slist_free(list) i also free the data contained by the elements ? Why all those memory leaks appear ? Is valgrind a suitable tool for profilinf memory issues when using a complex library like GLib ? LATER EDIT: If I g_slist_foreach(l,(GFunc)g_free,NULL);, the valgrind report is different, (All the memory leaks from 'definitely lost' will move to 'indirectly lost'). Still I don't see the point ? Aren't GLib collections implement a way to be freed ?

    Read the article

  • Passing window handler for the SFML

    - by Ockonal
    Hello, I'm using SFML Input system for my own application. Here is my code: size_t windowHnd = %MY_WINDOW_HANDLER%; sf::Window MyWindow(windowHnd); const sf::Input& MyInput = MyWindow.GetInput(); cannot convert ‘sf::Window’ to ‘size_t’ in assignment In official documentation I found sf::Window constructor signature: WindowHandle Handle What is the correct way to pass window handler for the SFML?

    Read the article

  • iPhone: Leak with UIWebView loading Office documents. Any ideas how to avoid it?

    - by Thomas Tempelmann
    While there are already quite a few posts about leaks around UIWebView, mine is a bit more special, I believe, and thus deserves its own post here. I see a reproducible large leak every time I load a Office document such as a Word or Excel file. For instance, every time I display a 180KB .doc file, I get a 100KB leak. And that happens with both the simulator and an actual device, running OS 3.1.3. The leak is not visible with the Leaks instrument but only by looking at the malloc instances via the ObjectAlloc instrument. Here's a picture from the instruments trace: I've also made a demo project, UIWebView-Leak.zip, so you can verify this yourself. To see the leak, use the ObjectAlloc instrument, switch to the view where you see individual allocation objects, and sort by size so that you see the large ones in a group, just like in my picture above. Then view a Office document a few times and find the Malloc objects that keep staying "Live" even after the actual UIWebView has been freed. Is this a known bug? Or is there any way I can avoid these leaks? I.e, have you successfully shown Office documents on an iPhone withing getting such leaks? Note: I've reported this as a bug to Apple now, too (ID 7950594) I am still waiting for someone (including Apple) to confirm this as a true leak or show why it isn't (i.e. that I do something wrong or make wrong assumptions)

    Read the article

  • (Amazon AWS) EBS mount error: Stale NFS file handle

    - by May
    I have an EC2 instance that just went offline (cannot even be pinged) but is still reflected as operational. In an effort to retrieve data stored on an attached EBS, I did a forced detach of the mounted volume, launched a new instance, and tried attaching the EBS volume. However, I keep getting an error - mount: Stale NFS file handle whenever I do so. Did I just lose all my files?

    Read the article

  • Can Airport Extremes handle NTFS external drives?

    - by Electrons_Ahoy
    I've got an Airport Extreme and an external USB Hard Drive formatted with NTFS. (And a LAN of Windows XP Machines.) The drive works perfectly when connected directly to a PC. When it's connected to the AE, however, the Airport Utility sees the drive and lists it in the Disks list, but the drive doesn't appear on the network (as near as I can tell.) Can the AE handle NTFS formatted disks? The documentation is vague on that point.

    Read the article

  • VMWare Workstation 8 reporting ""vmx86 driver version invalid handle" problem on booting VM

    - by dommer
    I'm just doing a VMWare Workstation 8 installation. However, on trying to boot (or create) a VM, it's reporting "Could not get vmx86 driver version: The handle is invalid." It recommends reinstalling, which I've done. Also, VMWare Player just hangs. Was going to post on the VMWare forums, but can't seem to create a new discussion (even though I've registered/logged in). It's our own fault for being too eager to upgrade, I guess.

    Read the article

  • .NET JIT Code Cache leaking?

    - by pitchfork
    We have a server component written in .Net 3.5. It runs as service on a Windows Server 2008 Standard Edition. It works great but after some time (days) we notice massive slowdowns and an increased working set. We expected some kind of memory leak and used WinDBG/SOS to analyze dumps of the process. Unfortunately the GC Heap doesn’t show any leak but we noticed that the JIT code heap has grown from 8MB after the start to more than 1GB after a few days. We don’t use any dynamic code generation techniques by our own. We use Linq2SQL which is known for dynamic code generation but we don’t know if it can cause such a problem. The main question is if there is any technique to analyze the dump and check where all this Host Code Heap blocks that are shown in the WinDBG dumps come from? [Update] In the mean time we did some more analysis and had Linq2SQL as probable suspect, especially since we do not use precompiled queries. The following example program creates exactly the same behaviour where more and more Host Code Heap blocks are created over time. using System; using System.Linq; using System.Threading; namespace LinqStressTest { class Program { static void Main(string[] args) { for (int i = 0; i < 100; ++ i) ThreadPool.QueueUserWorkItem(Worker); while(runs < 1000000) { Thread.Sleep(5000); } } static void Worker(object state) { for (int i = 0; i < 50; ++i) { using (var ctx = new DataClasses1DataContext()) { long id = rnd.Next(); var x = ctx.AccountNucleusInfos.Where(an => an.Account.SimPlayers.First().Id == id).SingleOrDefault(); } } var localruns = Interlocked.Add(ref runs, 1); System.Console.WriteLine("Action: " + localruns); ThreadPool.QueueUserWorkItem(Worker); } static Random rnd = new Random(); static long runs = 0; } } When we replace the Linq query with a precompiled one, the problem seems to disappear.

    Read the article

  • Handle URI hacking gracefully in ASP.NET

    - by asbjornu
    I've written an application that handles most exceptions gracefully, with the page's design intact and a pretty error message. My application catches them all in the Page_Error event and there adds the exception to HttpContext.Curent.Context.Items and then does a Server.Transfer to an Error.aspx page. I find this to be the only viable solution in ASP.NET as there seems to be no other way to do it in a centralized and generic manner. I also handle the Application_Error and there I do some inspection on the exception that occurred to find out if I can handle it gracefully or not. Exceptions I've found I can handle gracefully are such that are thrown after someone hacking the URI to contain characters the .NET framework considers dangerous or basically just illegal at the file system level. Such URIs can look like e.g.: http://exmample.com/"illegal" http://example.com/illegal"/ http://example.com/illegal / (notice the space before the slash at the end of the last URI). I'd like these URIs to respond with a "404 Not Found" and a friendly message as well as not causing any error report to be sent to avoid DDOS attack vectors and such. I have, however, not found an elegant way to catch these types of errors. What I do now is inspect the exception.TargetSite.Name property, and if it's equal to CheckInvalidPathChars, ValidatePath or CheckSuspiciousPhysicalPath, I consider it a "path validation exception" and respond with a 404. This seems like a hack, though. First, the list of method names is probably not complete in any way and second, there's the possibility that these method names gets replaced or renamed down the line which will cause my code to break. Does anyone have an idea how I can handle this less hard-coded and much more future-proof way? PS: I'm using System.Web.Routing in my application to have clean and sensible URIs, if that is of any importance to any given solution.

    Read the article

  • how to store a file handle in perl class

    - by Haiyuan Zhang
    please look at the following code first. #! /usr/bin/perl package foo; sub new { my $pkg = shift; my $self = {}; my $self->{_fd} = undef; bless $self, $pkg; return $self; } sub Setfd { my $self = shift; my $fd = shift; $self_->{_fd} = $fd; } sub write { my $self = shift; print $self->{_fd} "hello word"; } my $foo = new foo; My intention is to store a file handle within a class using hash. the file handle is undefined at first, but can be initilized afterwards by calling Setfd function. then write can be called to actually write string "hello word" to a file indicated by the file handle, supposed that the file handle is the result of a success "write" open. but, perl compiler just complains that there are syntax error in the "print" line. can anyone of you tells me what's wrong here? thanks in advance.

    Read the article

  • how to install a file handle in perl class

    - by Haiyuan Zhang
    please looku up the following code first. #! /usr/bin/perl package foo; sub new { my $pkg = shift; my $self = {}; my $self->{_fd} = undef; bless $self, $pkg; return $self; } sub Setfd { my $self = shift; my $fd = shift; $self_->{_fd} = $fd; } sub write { my $self = shift; print $self->{_fd} "hello word"; } my $foo = new foo; My intention is to store a file handle within a class using hash. the file handle is undefined at first, but can be initilized afterwards by calling Setfd function. then write can be called to actually write string "hello word" to a file indicated by the file handle, supposed that the file handle is the result of a success "write" open. but, perl compiler just complains that there are syntax error in the "print" line. can anyone of you tells me what's wrong here? thanks in advance.

    Read the article

  • How to handle Alarm notification in Android?

    - by Asheesh Vashishtha
    Hi, I'm developing an media player application for Android, for which I need to handle any Alarm notification, and based on that I'll pause my playback. When the Alarm in snoozed or dismissed, I'll then resume the playback. I googled a lot for the Alarm handling, but what I found was the way to enable Alarm notifications through code, set the intent and then handle it. However, no where could I locate just handling the Alarm notification part. I don't need to set the Alarm on, it could've been set by the user, and I don't need to programmatically. All I need is just handle that notification. Any ideas on this would be extremely useful? Thanks, Asheesh

    Read the article

  • NativeWindow WndProc not receiving messages

    - by BadNinja
    Could someone shed some light on why my WndProc method as implemented below isn't receiving any messages? If I put this class below in a WinForms application and pass in that application's handle, WndProc receives messages as I would expect. However, using the IntPtr returned from GetForegroundWindow() as I have below doesn't yield the same results. (FWIW, I have my code set up to execute GetForegroundWindow() when my application is hidden, so I'm certain that the IntPtr is referring to an outside application.) public class MyNativeWindow : NativeWindow { [DllImport("user32.dll", ExactSpelling = true, SetLastError = true)] private static extern IntPtr GetForegroundWindow(); public MyNativeWindow() { this.AssignHandle(GetForegroundWindow()); } // Never called... I set a breakpoint [System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name = "FullTrust")] protected override void WndProc(ref Message m) { base.WndProc(ref m); } }

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 11 12 13 14 15 16 17 18 19 20 21 22  | Next Page >