Menu
▾
▴
Re: [FreeWRL-develop] Bad Memory Access Issue
|
From: <dis...@uk...> - 2015-04-20 14:18:02
|
Hi Doug, I almost merge my improvements to develop branch... After I complete today I can send you zip with my changes or push them to some branch if you give me permission. Regarding the malloc - I already converted them to MALLOC everywhere (maybe except Sound module) to make able the hack with memory table freeing working. Regarding the freeing and profiling - I can help you in profiling of the models and tracking memory freeing. In Xcode there are tools for that, and what I observed last time I profiled with Xcode was next: Even if I delete all generated buffers from GL (with glDeleteBuffer), the memory was still retained in the GL internal context... After I free all MALLOCs from my memory table, on iOS devices the memory is freed immediately. P.S. FYI on iOS allocator works differently from Linux or Windows, and this can cause issues with x64 architecture there... My merged code will consist of intptr_t, size_t types for many many functions and offset tables. It will be interesting for me to know your opinion on that - if you think this is acceptable... If it is, we will need to find a way to modify the script which generates GeneratedCode.c instead of direct modification of .c file. P.P.S. Question: - there is main/SoundEngineClient.c - there is scenegraph/Component_Sound.c Both these files contain the same several function implementations, this brings linking errors. In which file these functions are correct? From which I can delete the same functions? Are both files needed for the project? - Disabler Disabler, I'm making progress on mallocs - 67MB recovered, another 61MB to go on Mars. -Doug I started with the biggest and worked down the list. Nothing too difficult on any one of them. But I need to convert some mallocs to MALLOCS to help find what the operating system still says I haven't recovered. Or do operating systems deal in big blocks, and if I have 2 bytes malloced, separated by 61 MB that I had malloced and freed, does the os still wait till big whole contiguous blocks are completely freed? After several fixes, Mars dataset (did have 67MB not freed before, now < 1MB, that;s tracked with DEBUG_MALLOC) unfreed: count size line file 1 5 249 ../../src\lib\main\MainLoop.c 670 10720 49 ../../src\lib\scenegraph\Vector.c 595 14128 53 ../../src\lib\scenegraph\Vector.c 1 16 272 ../../src\lib\vrml_parser\CRoutes.c 1 260 159 ../../src\lib\io_files.c 1 208 5715 ../../src\lib\scenegraph\GeneratedCode.c 75 10624 91 ../../src\lib\scenegraph\Vector.c 1 9 350 ../../src\lib\main.c 588 9408 42 ../../src\lib\list.c 68 656 524 ../../src\lib\vrml_parser\CRoutes.c 67 2680 256 ../../src\lib\io_files.c 1 384 5821 ../../src\lib\scenegraph\GeneratedCode.c 1 16000 1326 ../../src\lib\vrml_parser\CRoutes.c 876 21024 105 ../../src\lib\input\EAI_C_CommonFunctions.c 77 3233 108 ../../src\lib\input\EAI_C_CommonFunctions.c 1 12 5991 ../../src\lib\scenegraph\GeneratedCode.c 67 1072 4770 ../../src\lib\vrml_parser\CParseParser.c 67 469 4772 ../../src\lib\vrml_parser\CParseParser.c 74 1184 6681 ../../src\lib\scenegraph\GeneratedCode.c 136 8184 445 ../../src\lib\resources.c 36 1728 1851 ../../src\lib\scenegraph\Component_Geospatial.c 192 3840 1204 ../../src\lib\scenegraph\Component_Geospatial.c 1 48 367 ../../src\lib\scenegraph\Component_Grouping.c 2 32 1389 ../../src\lib\opengl\OpenGL_Utils.c 134 10060 160 ../../src\lib\resources.c 48 1536 2864 ../../src\lib\opengl\OpenGL_Utils.c 2 116 115 ../../src\lib\io_files.c total bytes not freed 117636 > >> After X3D_PolyRep is not needed anymore, should be invoked >> glDeleteBuffers(VBO_COUNT, rep->VBOs) >> >> And the same for all other GL 3D objects (cylinders, disks, ...) > Disabler, > Update: I got a polyrep cleanup function working, there's still a few textures and buffers left over for things like the statusbar/menubar - I'll continue. > -Doug > more.. > I'm also playing with the DEBUG_MALLOC in freewrl - for the Mars.x3d dataset a lot of memory goes missing that I though was in polyrep or gl buffer, but isn't. 67 MB in the table below, and another 50MB according to the operating system's TaskManager, that is missing and not in the table below. > There's a so-called PIMPL idiom for C that's supposed to make things more OO like C++ - an object owns and cleans up its own stuff. But there are producer-consumer patterns in freewrl, and one hypothesis: the big chunks are like that. > > > t1 t2 t3 b33 > gl buffers not freed = 1 > gl textures not freed = 3 > unfreed: > count size line file > 1 5 249 ../../src\lib\main\MainLoop.c > 954 15264 49 ../../src\lib\scenegraph\Vector.c > 846 16136 53 ../../src\lib\scenegraph\Vector.c > 1 16 272 ../../src\lib\vrml_parser\CRoutes.c > 582 51580 452 ../../src\lib\main\ConsoleMessage.c > 1 260 159 ../../src\lib\io_files.c > 1 208 5715 ../../src\lib\scenegraph\GeneratedCode.c > 320 9612224 91 ../../src\lib\scenegraph\Vector.c > 1 9 350 ../../src\lib\main.c > 918 14688 42 ../../src\lib\list.c > 106 5088 6680 ../../src\lib\scenegraph\GeneratedCode.c > 1804 15635074 775 ../../src\lib\input\EAI_C_CommonFunctions.c > 217 1912 524 ../../src\lib\vrml_parser\CRoutes.c > 99 15830272 339 ../../src\lib\io_files.c > 99 3960 256 ../../src\lib\io_files.c > 1 384 5821 ../../src\lib\scenegraph\GeneratedCode.c > 1 16000 1326 ../../src\lib\vrml_parser\CRoutes.c > 1268 30432 105 ../../src\lib\input\EAI_C_CommonFunctions.c > 1268 31081 108 ../../src\lib\input\EAI_C_CommonFunctions.c > 187 18166 735 ../../src\lib\input\EAI_C_CommonFunctions.c > 188 2996 107 ../../src\lib\scenegraph\Vector.c > 1 12 5991 ../../src\lib\scenegraph\GeneratedCode.c > 1 48 6891 ../../src\lib\scenegraph\GeneratedCode.c > 1 48 6896 ../../src\lib\scenegraph\GeneratedCode.c > 99 4752 6771 ../../src\lib\scenegraph\GeneratedCode.c > 99 1584 4770 ../../src\lib\vrml_parser\CParseParser.c > 99 693 4772 ../../src\lib\vrml_parser\CParseParser.c > 106 5088 6722 ../../src\lib\scenegraph\GeneratedCode.c > 106 7208 7372 ../../src\lib\scenegraph\GeneratedCode.c > 106 1696 6681 ../../src\lib\scenegraph\GeneratedCode.c > 205 12350 445 ../../src\lib\resources.c > 11 152 71 ../../src\lib\scenegraph\Component_Grouping.c > 1 48 367 ../../src\lib\scenegraph\Component_Grouping.c > 291 5820 1204 ../../src\lib\scenegraph\Component_Geospatial.c > 2 32 1389 ../../src\lib\opengl\OpenGL_Utils.c > 203 15060 160 ../../src\lib\resources.c > 99 11597500 1454 ../../src\lib\scenegraph\Component_Geospatial.c > 99 14229504 1552 ../../src\lib\scenegraph\Component_Geospatial.c > 72 2304 2864 ../../src\lib\opengl\OpenGL_Utils.c > 132 6336 1851 ../../src\lib\scenegraph\Component_Geospatial.c > 3 336 5845 ../../src\lib\scenegraph\GeneratedCode.c > 66 528 756 ../../src\lib\scenegraph\Component_Networking.c > 7 418 115 ../../src\lib\io_files.c > 4 96 644 ../../src\lib\scenegraph\Component_Geospatial.c > 1 24 770 ../../src\lib\scenegraph\Component_Geospatial.c > 7 168 846 ../../src\lib\scenegraph\Component_Geospatial.c > 3 72 1919 ../../src\lib\scenegraph\Component_Geospatial.c > 1 176 79 ../../src\lib\resources.c > 2 86 408 ../../src\lib\resources.c > 1 152 5830 ../../src\lib\scenegraph\GeneratedCode.c > 2 46152 1049 ../../src\lib\scenegraph\GenPolyRep.c > 2 144 457 ../../src\lib\opengl\Textures.c > 1 387096 297 ../../src\lib\scenegraph\StreamPoly.c > total bytes not freed 67611438 > >> >> Q. is it just the malloc cleanup? >> >> No, with malloc cleanup is everything fine there. >> It's with glBufferData. >> >> After X3D_PolyRep is not needed anymore, should be invoked >> glDeleteBuffers(VBO_COUNT, rep->VBOs) >> >> And the same for all other GL 3D objects (cylinders, disks, ...) >> >> --- Исходное сообщение --- >> От кого: "doug sanden" < hig...@ho... > >> Дата: 17 апреля 2015, 16:40:37 >> >> >> Disabler, >> Looks like I did something per-broto/executionContext in unload_broto() for removing the opengl textures, in March (last month). >> I'm thinking we should try and get you upgraded to the latest libfreewrl code -and vice-versa fix the backend code for you- so we are working on the same codebase and you can keep up with us. (you can keep your frontend / mobile-specific code private). >> Q. is it just the malloc cleanup? >> If so I can take a look this weekend, and see how best to apply your malloc table approach or equivalent. >> -Doug >> >> more.. >> malloc / free ideas: >> - there are a few functions that can automatically go over all fields in a node including private, and might work as a general approach to finding and freeing pointer fields >> - or fwmalloc(size,executionContext) >> - or all nodes could be given a __GC field for a malloc table, then field_malloc(size,node) >> Besides nodes, you mentioned strdup, and there are those texture table entries - I wonder what else. >> >>> GL buffers aren't deleted? Or no one needs that for now? >>> >>> e.g. when X3D_PolyRep is not needed anymore, it's VBOs continuing to >>> live in GPU forever until the GL context is dead... It could be crucial >>> to delete them for mobile platforms. >> >> Good question - I don't think VBO buffers get stuck in opengl -or perhaps just the very last one submitted doesn't get flushed. >> We would have noticed. However textures given to openGL just after images are mipmpapped, which is when they are loaded into memory. >> When I look at unload_broto() in the current version, when it unregisters it calls something for texture nodes ... >> >> Current version> Textures.c L.520 in registerTexture0(iaction=0,) >> >> releaseTexture(tmp); //Mar 23, 2015 added, to zap from gl texture name list (and its texture storage) >> >> //otherwise for geoLOD and inline, the OS MEM usage keeps going up after unload/load cycle >> >> >> >> But that didn't fix all the memory problem for the Mars.x3d dataset. >> http://dug9.users.sourceforge.net/web3d/tests/geo/Mars/Mars.x3d >> (It's hard to navigate to the planet with your version - I reworked navigation recently) >> It has a GeoLOD node which has 4 Inlines as child nodes. So its a good exercise for Inline unloading. >> And even after the March it eats memory with each reload. >> Hypothesis: >> H0: it's a malloc of a) public field data -in the Mars case its geometry like the terrain points on the surface of Mars- on a node or b) private fields like __VBO buffers, which aren't systematically freed. >> If so your global malloc table approach would likely have fixed it. >> >> By public field I mean the ones in the web3d.org specifications. >> By private I mean the __ fields our developers have added for optimization, for example to hold prepared VBO buffers. >> All nodes have >> struct X3D_PolyRep *_intern; >> which I think is where the VBO data is stored >> And some nodes have special private fields ie IndexedLineSet Structs.h L.3934 >> void * __vertArr; >> void * __vertIndx; >> void * __colours; >> void * __vertices; >> void * __vertexCount; >> int __segCount; >> >> Your gglobal malloc approach would get these (eventually) when garbage collecting gglobal. >> However not earlier such as when unloading an inline. >> http://dug9.users.sourceforge.net/web3d/tests/Inlines/inline_control.wrl >> - calls unload_broto, so will zap things but currently unload_broto isn't cleaning up public/private non-SFNode fields >> >> I mention SFNode fields separately, because changes last year >> add_node_to_broto_context(currentContext,node); >> put newly created nodes into their appropriate broto (Scene, Inline, Proto, ExterProto) context (X3DExecutionContext). >> And unload_broto frees the malloced node. But it does nothing about the private or public fields. >> >> more.. >> You could/should upgrade to the current version. Because the git code is a moving target, its a good idea for us to try and capture any of your needed libfreewrl (backend) modifications into the libfreewrl codebase, in a way that serves all. Your frontend modifications you can keep private. >> And I gather its the memory cleanup cycle right now that's the issue. >> >> >> >> >> >> >> >>> GL buffers aren't deleted? Or no one needs that for now? >>> >>> e.g. when X3D_PolyRep is not needed anymore, it's VBOs continuing to >>> live in GPU forever until the GL context is dead... It could be crucial >>> to delete them for mobile platforms. >>> >>> --- Исходное сообщение --- >>> От кого: "doug sanden" < hig...@ho... <mailto:hig...@ho...>> >>> Дата: 14 апреля 2015, 21:35:11 >>> >>> >>>> killNodes function which kills Nodes marked for dispose was not freeing >>>> the Node context, only Node instance itself. That resulted in the issue >>>> that textures were not removed from texture tables and at some time I >>>> was seeing 45 alive textures in texture table when each my single model >>>> file consists of 3-5 textures only. >>>> >>>> I added inside killNodes() unRegisterX3DAnyNode(node); before >>>> FREE_IF_NZ(node); to fix that. >>> >>> Disabler, >>> I think I also tinkered with killnodes recently - I'll need to check, - and thanks for your tip, >>> >>>> Also I noticed that X3D_Proto and X3D_Inline consist of __GC field, >>> >>> I probably put that in last year anticipating the memory cleanup would eventually be per-broto (per scene/inline/proto/execution context), I never got to it. So if you change your malloc table to per-context, you can use that. >>> -Doug >>> >>> more.. >>> A problem might be finding a handy executionContext that's valid. I think CparseParser is putting it in the nodes now during parsing ie node->_executionContext = (X3DNode * proto/inline/scene) >>> so there might be an appropriate executionContext handy when doing a malloc. >>> >>> But maybe not for textures - the TextureTableIndexStruct tti thing? >>> ImageTexture node 1:1 TextureTableIndexStruct 1:1 resource ? >>> Also, when we load and mipmap the texture, we hand it immediately to openGL. >>> Is there something we can/need to do to tell openGL to clear it? >>> >>> more.. >>> The old model of freewrl was a single process - a command line program running one scene, and variables were all static. No gglobal. When you exit, the process cleans up itself. >>> It's been a long journey to get so it can run 2 instances and tell the difference. >>> more.. >>> I'm working with large scenes now> 1GB RAM so I need good GC going forward. That means malloced data ownership rules need to be clarified. For now, per-context ownership would be an improvement >>> >>> >>> >>> >>> >>>> >>>> Sorry, didn't notice that I had not remove the message in my prev. >>>> email " Also, the reason why I switched from develop"... >>>> >>>> So, I will describe the story with more comments. >>>> Before jan. 2015 I was using not-develop branch, until I needed Android >>>> support. The older FreeWRL lib from that branch had problems on Samsung >>>> Android tablets with shaders. >>>> So that was the reason why I switched to develop #712dc2 on Jan. 11th >>>> 2015. The shaders work perfectly on Samsung tablets now. >>>> >>>> All my hacks with memory table and intptr_t were done then afterwards >>>> basing on #712dc2 from develop. >>>> >>>> Before I added memtable and switched from oldWorld-newWorld workflow to >>>> old gglobal-new gglobal, problems with memory which I saw to were next: >>>> >>>> killNodes function which kills Nodes marked for dispose was not freeing >>>> the Node context, only Node instance itself. That resulted in the issue >>>> that textures were not removed from texture tables and at some time I >>>> was seeing 45 alive textures in texture table when each my single model >>>> file consists of 3-5 textures only. >>>> >>>> I added inside killNodes() unRegisterX3DAnyNode(node); before >>>> FREE_IF_NZ(node); to fix that. >>>> >>>> Also I noticed comments in the code that somewhere it is hard to >>>> determine who owns SF/MF/UniString instances (are some of them shared >>>> between some nodes/protos/routes?) >>>> Char* instances after STRDUP are also the things which are owned in >>>> undefined way as it appeared to me. >>>> So to not deal with owning policies I assumed that for sure the highest >>>> owner is a gglobal and nothing should live after it dies, then I added >>>> a quick workaround with a global memory table. >>>> >>>> Also I noticed that X3D_Proto and X3D_Inline consist of __GC field, >>>> which as I suppose should have a role of something similar to my >>>> memtable, but Node-specific instead of gglobal-specific. Currently it >>>> is not used in revision I have. Are you planning to use it? :) >>>> >>>> Regards, >>>> Disabler >>>> >>>>> >>>>> FYI - I was using version from develop branch from the #712dc2 >>>>> (2014-12-06) revision. By that time, the issue with the newStack macro >>>>> had not been fixed yet. >>>>> >>>>> Also, the reason why I switched from develop >>>> Disabler, >>>> Q. What did you switch to? Or do you mean this was your initial fork revision, and you hacked starting from this? >>>> -Doug >>>> more.. >>>> If so then look in CParseParser.c L. 7144 gc_broto_instance() >>>> - Broto is my nickname for binary proto, or X3DProto, with the flat tables of nodes. >>>> L 7194 >>>> FREE_IF_NZ(nx); >>>> That's just freeing the node that was allocated in the executionContext/Broto >>>> - but I think non SFNode and MFNode public fields that were malloced could also be freed here >>>> - and anything allocated in prep_ and compile_ etc functions for a specific node >>>> - or else If you have a special malloc function then you could do like node creation ie >>>> val = disabler_malloc(size,context) >>>> which would need to get the broto/executioncontext similar to cparseparser.c L3682 >>>> >>>> node->_executionContext = X3D_NODE(currentContext); //me->ptr; >>>> add_node_to_broto_context(currentContext,node); >>>> >>>> more.. >>>> Here's a scene with some inline nodes - as you get closer (or father) it loads and unloads heavy geometry: >>>> http://dug9.users.sourceforge.net/web3d/tests/geo/Mars/Mars.x3d >>>> - in the current freewrl, the memory usage keeps creeping up, I suspect mostly because the geometry points aren't being freed as the inline is unloaded. >>>> >>>> >>>> >>>> >>>>> >>>>> 14 апреля 2015, 19:59:56, от < dis...@uk... <mailto:dis...@uk...><mailto:dis...@uk...><mailto:dis...@uk...><mailto:dis...@uk...>>: >>>>> >>>>> >>>>> Hi Doug, >>>>> >>>>>>> Could you please add me to issue reporters list, maybe I will find >>>>>>> something else :) >>>>> >>>>>> This is the issues reporter/developer's list >>>>> >>>>> I meant that on SourceFourge there's a Ticket creation possibility >>>>> ( http://sourceforge.net/p/freewrl/bugs/?source=navbar ), but it is not >>>>> allowed to create tickets for not authorized users. >>>>> >>>>>> It's been running 64 bit on linux for> 5 years, and I've been >>>>> building and running it x64 on windows for 3 weeks, no memory problems >>>>> >>>>> For me on iOS it was also without memory access problems until I added >>>>> 64bit support and designed the freeing of the memory. Then I started to >>>>> receive Nodes with incorrect data inside, and Vectors with n>20000000, >>>>> which indicated that: >>>>> a) or somewhere the memory was written incorrectly (the case with >>>>> newStack macro was the cause of that) >>>>> b) or somewhere the memory was incorrectly dereferenced after usage of >>>>> offsetPointer_deref or raw pointer dereferencing. >>>>> >>>>> First I avoided the possibility of the problem b) by changing int type >>>>> to intptr_t in offsets, int to size_t in memory allocation calls, then >>>>> - a). And I am not 100% sure that problem b) will or won't happen if >>>>> problem a) has been fixed by me first. >>>>> After problem b) fix (without a) yet) I started to recieve a proper n >>>>> in Vectors, but still bad accessing was present. >>>>> >>>>> So, as I suppose, with usage of intptr_t type for offsets the library >>>>> is more stable on arm64 architecture on iOS and also will clearly >>>>> identify where the developer uses just int, and where he requires a >>>>> memory-specific int which is intptr_t or ptrdiff_t. >>>>> >>>>> Now I have a stable version on iOS and Android, so I will not merge it >>>>> to the develop branch for now. Sorry :) >>>>> >>>>>> experience with multiple gglobal instances >>>>> >>>>> In implementation which I am using currently there's a single gglobal >>>>> at the same time, it is initialized in the display thread. Global >>>>> memory table is stored in the gglobal. >>>>> On iOS/Android apps my screen with FreeWrl models can be represented >>>>> multiple times. >>>>> So I needed a proper memory freeing. >>>>> I added registration of all allocations and freeings into the memory >>>>> table of current gglobal, so that memory table should always store only >>>>> alive objects... >>>>> >>>>> To safely free the memory with implementation which I'm using, all >>>>> contexts and threads of gglobal should be disposed first. (memory will >>>>> not be freed in case of replaceOldWorld for example). >>>>> >>>>> So when there is a call to fwl_init_instance, I am doing >>>>> fwl_doQuitInstance of the previous instance, inside the doQuitInstance >>>>> I am creating a dispose thread where old instance dies gracefully and >>>>> the memory table associated with it is freed. >>>>> >>>>> I have no need in EAN, JavaScript, and so on, only plain VRML 2.0 with >>>>> local files loading, so it could be that for other cases something will >>>>> not work. >>>>> >>>>> Also in the version I am using I improved the loading of local files by >>>>> adding a callback function, which library will call when it needs a >>>>> file from the front end. >>>>> >>>>> If you are still interested, I can send you my iOS and Android stable >>>>> versions (adopted to intptr_t, unfortunately by direct modification of >>>>> GeneratedCode.c and almost all files in x3d folder :)), where there >>>>> will be also seen memory table implementation and work with >>>>> consequential gglobal instantiations. >>>>> >>>>> Also soon I will add the memory table logic to the code from the >>>>> freeWRL develop branch and test it for stability on 64-bit iOS >>>>> platform. >>>>> >>>>> Best Regards, >>>>> Disabler >>>>> >>>>> Welcome Disabler. >>>>> >>>>>> I've implemented a special memory table >>>>> >>>>> Wow! >>>>> >>>>>> Then I've determined that library not crafted for 64-bit architecture >>>>> It's been running 64 bit on linux for> 5 years, and I've been building and running it x64 on windows for 3 weeks, no memory problems, however we haven't been challenging it by using 2+ instances of gglobal at the same time. >>>>> >>>>>> #define newStack(type) \ >>>>>> newVector((int) sizeof(type), 4) >>>>>> So, the library always creates Stack which is actually Vector with >>>>>> elSize = sizeof(int), and not the correct elSize of the structure or >>>>> >>>>> This problem sounds familiar. >>>>> When I check the current git develop branch, Vector.h L.122 >>>>> #define newStack(type) \ >>>>> newVector(type, 4) >>>>> >>>>> Hypothesis: you're using an older branch. >>>>> Here's the current development branch: >>>>> http://sourceforge.net/p/freewrl/git/ci/develop/tree/ >>>>> >>>>> We should make our website clearer about whats the latest. Thanks for bringing our attention to that. >>>>> >>>>>> Could you please add me to issue reporters list, maybe I will find >>>>>> something else :) >>>>> >>>>> This is the issues reporter/developer's list. You're in the right place. All the freewrl gurus are here, although they check their emails at different times of the day. >>>>> >>>>> Sounds like you're very familiar with the freewrl code now. That could be useful. How about trying the latest development branch and see if its' any better for you. Then we can go over some of the interesting things you are working on -such as memory tables, and your experience with multiple gglobal instances- and see what if anything we can/should apply to the current branch. >>>>> >>>>> -Doug >>>>> >>>>> >>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm trying to use the library on iOS and to make it not leak on memory >>>>>> I've implemented a special memory table (by reusing mechanisms of >>>>>> DEBUG_MALLOC redefinitions of MALLOC, REALLOC, FREE, STRDUP, etc, >>>>>> already present in the library). >>>>>> After I implemented a freeing of objects which were not freed by >>>>>> library during lifetime of gglobal instance, next situation appeared: >>>>>> >>>>>> 1st usage with 1st gglobal - normal behavior, model file successfully loads. >>>>>> 2nd usage with 2nd gglobal - crash on bad access in random places (even >>>>>> in native iOS component objects accessing). >>>>>> >>>>>> Then I've determined that library not crafted for 64-bit architecture >>>>>> with always 32-bit pointer arithmetic - and I replaced types in all >>>>>> ...Offset fields of structures, offset variables and offset tables to >>>>>> intptr_t. >>>>>> >>>>>> But Bad Access issue was still there. >>>>>> So finally the problem was localized: >>>>>> in Vector.h file: >>>>>> #define newStack(type) \ >>>>>> newVector((int) sizeof(type), 4) >>>>>> #define deleteStack(type, me) \ >>>>>> deleteVector((int) sizeof(type), me) >>>>>> at the same time: >>>>>> struct Vector* newVector_(int elSize, int initSize,char *,int); >>>>>> #define newVector(type, initSize) \ >>>>>> newVector_((int)sizeof(type), initSize,__FILE__,__LINE__) >>>>>> So, the library always creates Stack which is actually Vector with >>>>>> elSize = sizeof(int), and not the correct elSize of the structure or >>>>>> pointer which will be stored in the stack. >>>>>> Stack macros should look like this: >>>>>> #define newStack(type) \ >>>>>> newVector(type, 4) >>>>>> #define deleteStack(type, me) \ >>>>>> deleteVector(type, me) >>>>>> Could you please add me to issue reporters list, maybe I will find >>>>>> something else :) >>>>> >>>>> I think this is the issues reporter list. All the freewrl gurus are here. >>>>> >>>>>> >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Disabler... >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>>>> Develop your own process in accordance with the BPMN 2 standard >>>>> Learn Process modeling best practices with Bonita BPM through live exercises >>>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >>>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>>>> _______________________________________________ >>>>> FreeWRL-develop mailing list >>>>> Fre...@li... <mailto:Fre...@li...><mailto:Fre...@li...><mailto:Fre...@li...><mailto:Fre...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/freewrl-develop >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>>>> Develop your own process in accordance with the BPMN 2 standard >>>>> Learn Process modeling best practices with Bonita BPM through live exercises >>>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >>>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>>>> >>>>> >>>>> _______________________________________________ >>>>> FreeWRL-develop mailing list >>>>> Fre...@li... <mailto:Fre...@li...><mailto:Fre...@li...><mailto:Fre...@li...><mailto:Fre...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/freewrl-develop >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop >>>>> your own process in accordance with the BPMN 2 standard Learn Process >>>>> modeling best practices with Bonita BPM through live exercises >>>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>>>> event?utm_ >>>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>>>> _______________________________________________ FreeWRL-develop mailing >>>>> list Fre...@li... <mailto:Fre...@li...><mailto:Fre...@li...><mailto:Fre...@li...> >>>>> https://lists.sourceforge.net/lists/listinfo/freewrl-develop >>>> >>>> ------------------------------------------------------------------------------ >>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>>> Develop your own process in accordance with the BPMN 2 standard >>>> Learn Process modeling best practices with Bonita BPM through live exercises >>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>>> _______________________________________________ >>>> FreeWRL-develop mailing list >>>> Fre...@li... <mailto:Fre...@li...><mailto:Fre...@li...><mailto:Fre...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/freewrl-develop >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop >>>> your own process in accordance with the BPMN 2 standard Learn Process >>>> modeling best practices with Bonita BPM through live exercises >>>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>>> event?utm_ >>>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>>> _______________________________________________ FreeWRL-develop mailing >>>> list Fre...@li... <mailto:Fre...@li...><mailto:Fre...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/freewrl-develop >>> >>> ------------------------------------------------------------------------------ >>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >>> Develop your own process in accordance with the BPMN 2 standard >>> Learn Process modeling best practices with Bonita BPM through live exercises >>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>> _______________________________________________ >>> FreeWRL-develop mailing list >>> Fre...@li... <mailto:Fre...@li...><mailto:Fre...@li...> >>> https://lists.sourceforge.net/lists/listinfo/freewrl-develop >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop >>> your own process in accordance with the BPMN 2 standard Learn Process >>> modeling best practices with Bonita BPM through live exercises >>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >>> event?utm_ >>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >>> _______________________________________________ FreeWRL-develop mailing >>> list Fre...@li... <mailto:Fre...@li...> >>> https://lists.sourceforge.net/lists/listinfo/freewrl-develop >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT >> Develop your own process in accordance with the BPMN 2 standard >> Learn Process modeling best practices with Bonita BPM through live exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ >> FreeWRL-develop mailing list >> Fre...@li... <mailto:Fre...@li...> >> https://lists.sourceforge.net/lists/listinfo/freewrl-develop >> >> >> >> ------------------------------------------------------------------------------ >> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop >> your own process in accordance with the BPMN 2 standard Learn Process >> modeling best practices with Bonita BPM through live exercises >> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- >> event?utm_ >> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF >> _______________________________________________ FreeWRL-develop mailing >> list Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freewrl-develop > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > FreeWRL-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freewrl-develop ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ FreeWRL-develop mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freewrl-develop |