From: SourceForge.net <no...@so...> - 2012-04-11 19:40:16
|
Bugs item #3516990, was opened at 2012-04-11 12:40 Message generated for change (Tracker Item Submitted) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Nobody/Anonymous (nobody) Summary: Leaking memory in a thousand places Initial Comment: sdcc leaks memory. The attached file was produced using valgrind --num-callers=16 --leak-check=yes sdcc --std-c99 -mz80 -c -I../include/ -I../../libcv/include --opt-code-size --fverbose-asm --max-allocs-per-node 10000 cvu_play_music.c 2> log OK, it doesn\'t really show a thousand leaks - I already fixed a few, so it\'s down to 904 now. Similar results can be obtained by compiling any file for any target. The file I compiled is small; leaks are a more serious problem for larger source files. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-04-11 19:42:20
|
Bugs item #3516990, was opened at 2012-04-11 12:40 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Nobody/Anonymous (nobody) Summary: Leaking memory in a thousand places Initial Comment: sdcc leaks memory. The attached file was produced using valgrind --num-callers=16 --leak-check=yes sdcc --std-c99 -mz80 -c -I../include/ -I../../libcv/include --opt-code-size --fverbose-asm --max-allocs-per-node 10000 cvu_play_music.c 2> log OK, it doesn\'t really show a thousand leaks - I already fixed a few, so it\'s down to 904 now. Similar results can be obtained by compiling any file for any target. The file I compiled is small; leaks are a more serious problem for larger source files. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-04-11 12:42 Message: The list of leaks has been placed at http://pholia.tdi.informatik.uni-frankfurt.de/~philipp/log since it exceeds the sourceforge file size limit. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-04-11 21:42:13
|
Bugs item #3516990, was opened at 2012-04-11 12:40 Message generated for change (Comment added) made by tecodev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Nobody/Anonymous (nobody) Summary: Leaking memory in a thousand places Initial Comment: sdcc leaks memory. The attached file was produced using valgrind --num-callers=16 --leak-check=yes sdcc --std-c99 -mz80 -c -I../include/ -I../../libcv/include --opt-code-size --fverbose-asm --max-allocs-per-node 10000 cvu_play_music.c 2> log OK, it doesn\'t really show a thousand leaks - I already fixed a few, so it\'s down to 904 now. Similar results can be obtained by compiling any file for any target. The file I compiled is small; leaks are a more serious problem for larger source files. Philipp ---------------------------------------------------------------------- >Comment By: Raphael Neider (tecodev) Date: 2012-04-11 14:42 Message: I generally agree that avoiding memory leaks is a good idea. However, SDCC is a compiler, not a long-running daemon, job, or task. For SDCC, releasing all memory allocated during its lifetime costs a significant amount of runtime (I tested that on the pic backend once when I introduced control flow graph dumps for debugging purposes); letting the OS clean up after the process exits is much faster. Releasing memory can also introduce subtle bugs by prematurely freeing memory which is still in use (painfully experienced with pcode nodes in one of the pic backends once). Of course, not freeing unused memory can also hide bugs ... I would vote against "fixing" sdcc memory leaks with the sole purpose of reducing the number of complaints emitted by valgrind or similar tools. At least, I would heavily reduce the priority of these fixes. Just my two cents. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-04-11 12:42 Message: The list of leaks has been placed at http://pholia.tdi.informatik.uni-frankfurt.de/~philipp/log since it exceeds the sourceforge file size limit. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-04-11 21:57:00
|
Bugs item #3516990, was opened at 2012-04-11 12:40 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Nobody/Anonymous (nobody) Summary: Leaking memory in a thousand places Initial Comment: sdcc leaks memory. The attached file was produced using valgrind --num-callers=16 --leak-check=yes sdcc --std-c99 -mz80 -c -I../include/ -I../../libcv/include --opt-code-size --fverbose-asm --max-allocs-per-node 10000 cvu_play_music.c 2> log OK, it doesn\'t really show a thousand leaks - I already fixed a few, so it\'s down to 904 now. Similar results can be obtained by compiling any file for any target. The file I compiled is small; leaks are a more serious problem for larger source files. Philipp ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2012-04-11 14:57 Message: I agree with Raphael. You have to carry around all pointers to allocated memory so you can release them somewhere at the end of the runtime. While the OS will clean it all for you in one sweep. I suggest to set this one to Resolution: Wont Fix. ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2012-04-11 14:42 Message: I generally agree that avoiding memory leaks is a good idea. However, SDCC is a compiler, not a long-running daemon, job, or task. For SDCC, releasing all memory allocated during its lifetime costs a significant amount of runtime (I tested that on the pic backend once when I introduced control flow graph dumps for debugging purposes); letting the OS clean up after the process exits is much faster. Releasing memory can also introduce subtle bugs by prematurely freeing memory which is still in use (painfully experienced with pcode nodes in one of the pic backends once). Of course, not freeing unused memory can also hide bugs ... I would vote against "fixing" sdcc memory leaks with the sole purpose of reducing the number of complaints emitted by valgrind or similar tools. At least, I would heavily reduce the priority of these fixes. Just my two cents. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-04-11 12:42 Message: The list of leaks has been placed at http://pholia.tdi.informatik.uni-frankfurt.de/~philipp/log since it exceeds the sourceforge file size limit. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-04-12 07:03:55
|
Bugs item #3516990, was opened at 2012-04-11 12:40 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Nobody/Anonymous (nobody) Summary: Leaking memory in a thousand places Initial Comment: sdcc leaks memory. The attached file was produced using valgrind --num-callers=16 --leak-check=yes sdcc --std-c99 -mz80 -c -I../include/ -I../../libcv/include --opt-code-size --fverbose-asm --max-allocs-per-node 10000 cvu_play_music.c 2> log OK, it doesn\'t really show a thousand leaks - I already fixed a few, so it\'s down to 904 now. Similar results can be obtained by compiling any file for any target. The file I compiled is small; leaks are a more serious problem for larger source files. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-04-12 00:03 Message: I might not be worth chasing after every single byte. The end of the file shows a summary: ==12706== LEAK SUMMARY: ==12706== definitely lost: 686,329 bytes in 24,655 blocks ==12706== indirectly lost: 958,291 bytes in 38,944 blocks ==12706== possibly lost: 0 bytes in 0 blocks ==12706== still reachable: 836,625 bytes in 8,389 blocks ==12706== suppressed: 0 bytes in 0 blocks which means we lose a total of over one and a half Megabytes of memory for a file containing a single function of moderate size. I will investigate later today how this scales with file and function size. But I suspect that for larger files (e.g. autogenerated, due to programming style or just the input mentioned in the "implementation limits" of the standard) we might use an additional hundred megabytes or so due to leaks. Philipp P.S.: The leaks in the file seems to be sorted smallest-to-largest, so just fixing the last few ones could be a big improvement. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-04-11 14:57 Message: I agree with Raphael. You have to carry around all pointers to allocated memory so you can release them somewhere at the end of the runtime. While the OS will clean it all for you in one sweep. I suggest to set this one to Resolution: Wont Fix. ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2012-04-11 14:42 Message: I generally agree that avoiding memory leaks is a good idea. However, SDCC is a compiler, not a long-running daemon, job, or task. For SDCC, releasing all memory allocated during its lifetime costs a significant amount of runtime (I tested that on the pic backend once when I introduced control flow graph dumps for debugging purposes); letting the OS clean up after the process exits is much faster. Releasing memory can also introduce subtle bugs by prematurely freeing memory which is still in use (painfully experienced with pcode nodes in one of the pic backends once). Of course, not freeing unused memory can also hide bugs ... I would vote against "fixing" sdcc memory leaks with the sole purpose of reducing the number of complaints emitted by valgrind or similar tools. At least, I would heavily reduce the priority of these fixes. Just my two cents. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-04-11 12:42 Message: The list of leaks has been placed at http://pholia.tdi.informatik.uni-frankfurt.de/~philipp/log since it exceeds the sourceforge file size limit. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-05-28 20:50:08
|
Bugs item #3516990, was opened at 2012-04-11 12:40 Message generated for change (Comment added) made by mz-fuzzy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Nobody/Anonymous (nobody) Summary: Leaking memory in a thousand places Initial Comment: sdcc leaks memory. The attached file was produced using valgrind --num-callers=16 --leak-check=yes sdcc --std-c99 -mz80 -c -I../include/ -I../../libcv/include --opt-code-size --fverbose-asm --max-allocs-per-node 10000 cvu_play_music.c 2> log OK, it doesn\'t really show a thousand leaks - I already fixed a few, so it\'s down to 904 now. Similar results can be obtained by compiling any file for any target. The file I compiled is small; leaks are a more serious problem for larger source files. Philipp ---------------------------------------------------------------------- Comment By: Martin Matyas (mz-fuzzy) Date: 2012-05-28 13:50 Message: I'd vote for fixing at least biggest leaks. In my case, I'd like to squeeze my z80 code size as much as possible, but with my PC's 8GB RAM I'm able to set max-allocs-per-node to "only" about 6 million; I'd like to have possiblilty to run compilation overnight and get best possible code size with max-allocs-per-node like 60 million or so. I assume that this memory consumption is caused by not freed memory during compilation (please correct me if I'm wrong). Martin ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-04-12 00:03 Message: I might not be worth chasing after every single byte. The end of the file shows a summary: ==12706== LEAK SUMMARY: ==12706== definitely lost: 686,329 bytes in 24,655 blocks ==12706== indirectly lost: 958,291 bytes in 38,944 blocks ==12706== possibly lost: 0 bytes in 0 blocks ==12706== still reachable: 836,625 bytes in 8,389 blocks ==12706== suppressed: 0 bytes in 0 blocks which means we lose a total of over one and a half Megabytes of memory for a file containing a single function of moderate size. I will investigate later today how this scales with file and function size. But I suspect that for larger files (e.g. autogenerated, due to programming style or just the input mentioned in the "implementation limits" of the standard) we might use an additional hundred megabytes or so due to leaks. Philipp P.S.: The leaks in the file seems to be sorted smallest-to-largest, so just fixing the last few ones could be a big improvement. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-04-11 14:57 Message: I agree with Raphael. You have to carry around all pointers to allocated memory so you can release them somewhere at the end of the runtime. While the OS will clean it all for you in one sweep. I suggest to set this one to Resolution: Wont Fix. ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2012-04-11 14:42 Message: I generally agree that avoiding memory leaks is a good idea. However, SDCC is a compiler, not a long-running daemon, job, or task. For SDCC, releasing all memory allocated during its lifetime costs a significant amount of runtime (I tested that on the pic backend once when I introduced control flow graph dumps for debugging purposes); letting the OS clean up after the process exits is much faster. Releasing memory can also introduce subtle bugs by prematurely freeing memory which is still in use (painfully experienced with pcode nodes in one of the pic backends once). Of course, not freeing unused memory can also hide bugs ... I would vote against "fixing" sdcc memory leaks with the sole purpose of reducing the number of complaints emitted by valgrind or similar tools. At least, I would heavily reduce the priority of these fixes. Just my two cents. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-04-11 12:42 Message: The list of leaks has been placed at http://pholia.tdi.informatik.uni-frankfurt.de/~philipp/log since it exceeds the sourceforge file size limit. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-05-28 20:53:00
|
Bugs item #3516990, was opened at 2012-04-11 12:40 Message generated for change (Comment added) made by mz-fuzzy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Nobody/Anonymous (nobody) Summary: Leaking memory in a thousand places Initial Comment: sdcc leaks memory. The attached file was produced using valgrind --num-callers=16 --leak-check=yes sdcc --std-c99 -mz80 -c -I../include/ -I../../libcv/include --opt-code-size --fverbose-asm --max-allocs-per-node 10000 cvu_play_music.c 2> log OK, it doesn\'t really show a thousand leaks - I already fixed a few, so it\'s down to 904 now. Similar results can be obtained by compiling any file for any target. The file I compiled is small; leaks are a more serious problem for larger source files. Philipp ---------------------------------------------------------------------- Comment By: Martin Matyas (mz-fuzzy) Date: 2012-05-28 13:52 Message: ... for ~1200 line-of-code module, forgot to note. ---------------------------------------------------------------------- Comment By: Martin Matyas (mz-fuzzy) Date: 2012-05-28 13:50 Message: I'd vote for fixing at least biggest leaks. In my case, I'd like to squeeze my z80 code size as much as possible, but with my PC's 8GB RAM I'm able to set max-allocs-per-node to "only" about 6 million; I'd like to have possiblilty to run compilation overnight and get best possible code size with max-allocs-per-node like 60 million or so. I assume that this memory consumption is caused by not freed memory during compilation (please correct me if I'm wrong). Martin ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-04-12 00:03 Message: I might not be worth chasing after every single byte. The end of the file shows a summary: ==12706== LEAK SUMMARY: ==12706== definitely lost: 686,329 bytes in 24,655 blocks ==12706== indirectly lost: 958,291 bytes in 38,944 blocks ==12706== possibly lost: 0 bytes in 0 blocks ==12706== still reachable: 836,625 bytes in 8,389 blocks ==12706== suppressed: 0 bytes in 0 blocks which means we lose a total of over one and a half Megabytes of memory for a file containing a single function of moderate size. I will investigate later today how this scales with file and function size. But I suspect that for larger files (e.g. autogenerated, due to programming style or just the input mentioned in the "implementation limits" of the standard) we might use an additional hundred megabytes or so due to leaks. Philipp P.S.: The leaks in the file seems to be sorted smallest-to-largest, so just fixing the last few ones could be a big improvement. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-04-11 14:57 Message: I agree with Raphael. You have to carry around all pointers to allocated memory so you can release them somewhere at the end of the runtime. While the OS will clean it all for you in one sweep. I suggest to set this one to Resolution: Wont Fix. ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2012-04-11 14:42 Message: I generally agree that avoiding memory leaks is a good idea. However, SDCC is a compiler, not a long-running daemon, job, or task. For SDCC, releasing all memory allocated during its lifetime costs a significant amount of runtime (I tested that on the pic backend once when I introduced control flow graph dumps for debugging purposes); letting the OS clean up after the process exits is much faster. Releasing memory can also introduce subtle bugs by prematurely freeing memory which is still in use (painfully experienced with pcode nodes in one of the pic backends once). Of course, not freeing unused memory can also hide bugs ... I would vote against "fixing" sdcc memory leaks with the sole purpose of reducing the number of complaints emitted by valgrind or similar tools. At least, I would heavily reduce the priority of these fixes. Just my two cents. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-04-11 12:42 Message: The list of leaks has been placed at http://pholia.tdi.informatik.uni-frankfurt.de/~philipp/log since it exceeds the sourceforge file size limit. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3516990&group_id=599 |