Thread (8 messages) flat view 8 messages, 2 authors, 2016-06-15

Re: git-fast-export is returning streams with source code inside

From: James Gregory <hidden>
Date: 2016-06-15 22:51:45

Hi Peff,

Thanks for the feedback. I've just looked at the commit on gitweb, and
this could be the problem!

---
fixed dodgy filename
spec/blueprints/sjt_blueprint.rb	[moved from
spec/blueprints/sjt_blueprint.rb\n lead_in\n scenario\n answers {
Sham.answers_object }\n justification_selected\n
justification_unselected\n mark_scheme {
Sham.single_mark_scheme_object }\nend\nmcq_blueprint.rb with 100%
similarity]
---

I'm guessing that is where the problem lies... somehow the git
transaction has got corrupt(?)

James

On 5 August 2011 10:36, Jeff King [off-list ref] wrote:
On Fri, Aug 05, 2011 at 10:24:07AM +0100, James Gregory wrote:
quoted
I've attached the valgrind.out file. If I'm reading the output
properly, it does look like it is suffering from a memory leak.
It looks pretty innocuous:
quoted
==3267== Conditional jump or move depends on uninitialised value(s)
==3267==    at 0x4E39510: inflateReset2 (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==3267==    by 0x4E39605: inflateInit2_ (in /lib/x86_64-linux-gnu/libz.so.1.2.3.4)
==3267==    by 0x4D5B02: ??? (in /usr/bin/git)
==3267==    by 0x4BB059: ??? (in /usr/bin/git)
==3267==    by 0x4BC464: ??? (in /usr/bin/git)
==3267==    by 0x4BCA29: ??? (in /usr/bin/git)
==3267==    by 0x4BCAFD: ??? (in /usr/bin/git)
==3267==    by 0x4BD161: ??? (in /usr/bin/git)
==3267==    by 0x49AEAC: ??? (in /usr/bin/git)
==3267==    by 0x4B38AA: ??? (in /usr/bin/git)
==3267==    by 0x4B422A: ??? (in /usr/bin/git)
==3267==    by 0x4A9CD2: ??? (in /usr/bin/git)
This is a well-known false positive caused by zlib, and is nothing to
worry about.
quoted
==3267== LEAK SUMMARY:
==3267==    definitely lost: 48,016 bytes in 3 blocks
==3267==    indirectly lost: 30,226 bytes in 1,889 blocks
These are actual leaks, but minor.
quoted
==3267==      possibly lost: 0 bytes in 0 blocks
==3267==    still reachable: 2,743,134 bytes in 4,334 blocks
These are not really leaks, but rather things we don't bother cleaning
up since we're about to exit and let the OS reclaim memory (e.g., all of
the commit objects).

So yes, there's leaking, but it's not much. And more importantly, I was
looking not for leaks, but for memory access errors (of which there are
none, except for the zlib false positive).

So I'm not sure where to go from here. I can't reproduce the problem
locally. Is there anything else you can tell us about the problem? Does
it always happen on the same commit? If you export just that commit,
does the problem happen? Is there anything noteworthy in the contents of
that commit?

-Peff


-- 

James Gregory
Senior Developer
epiGenesys - a University of Sheffield company
Enterprise Zone, Portobello, Sheffield, S1 4DP, UK
T: +44 (0)114 22 21884 ~ F: +44 (0)114 22 24042
www.epigenesys.co.uk ~ @epigenesys
--
This email and its attachments should be considered confidential and
are intended solely for the individual to whom the email is addressed.
If you are not the intended recipient you should take no action based
upon them, nor should you copy or show them to anyone. Any views or
opinions expressed are solely those of the author and might not
represent those of Epi Genesys Limited.
Epi Genesys Limited is registered in England and Wales with company
number 06388971 and has its registered office at 40 Leavygreave Road,
Sheffield, S3 7RD.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help