Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Markus Wanner
Hi,

Daniel Atallah wrote:
 c:\Program Files\monotone\mtn.exe: fatal: memory access violation
 this is almost certainly a bug in monotone.
 please send this error message, the output of 'c:\Program 
 Files\monotone\mtn.exe
  version --full',
 and a description of what you were doing to monotone-devel@nongnu.org

Hm.. I get similar errors on Gentoo Hardenen during unit tests. Might
not be related at all, but I'm still wondering where these come from.

 Clearly this isn't a major problem, but I figured I should report it.

Thanks for your report. Did you (or anybody else on MinGW) run the test
suite for 0.42?

rant I'm trying to get MinGW installed, but Windoze is so damn
uncomfortable! /rant

Regards

Markus Wanner


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Zbigniew Zagórski
Hi all,

2009/1/7 Markus Wanner mar...@bluegap.ch:
 ...
 Thanks for your report. Did you (or anybody else on MinGW) run the test
 suite for 0.42?

Yep, i've ran test suite before publishing binaries. There were no ...
err,  almost no failures.
At least no significant ones.

Failures:
   util_mtnopt   because windows doesn't have /bin/sh usually installed
   automate_lua  because 3.4 on polish locale is 3,4 grrr

They are: 1. minor, 2. unrelated

I forgot to report them never mind having time to fix.

Best regards,
Zbyszek


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Markus Wanner
Hi,

Zbigniew Zagórski wrote:
 Yep, i've ran test suite before publishing binaries. There were no ...
 err,  almost no failures.
 At least no significant ones.

Cool, thanks.

 Failures:
util_mtnopt   because windows doesn't have /bin/sh usually installed
automate_lua  because 3.4 on polish locale is 3,4 grrr
 
 They are: 1. minor, 2. unrelated
 
 I forgot to report them never mind having time to fix.

Can you reproduce what the OP reported?

Regards

Markus Wanner


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Zbigniew Zagórski
Hi,

2009/1/7 Markus Wanner mar...@bluegap.ch:
 ...
 Can you reproduce what the OP reported?

Unfortunately no (and yes ... see the end)

In fact mtn diff --external doesn't work OOB because it tries to pass
arguments to execute in wrong way or lua execute is broken on win32.
Nevertheless lua execute doesn't quote strings with tabs.  I can't find
definition of lua execute to confirm this.

When I fixed this the only thing i've got after doing CTRL+C while
 kdiff3 was running was:

mtn: botan_pipe_cache.hh:41: invariant 'I(!pipe)' violated
mtn: saving current work set: 4 items

in debug log.

And all of this was using msys shell. But at some time while writing this post
i realized that windowz has also native shell, so ..

When using cmd as shell I can reproduce the bug and it appears
to be very strange.

I use kdiff3 as external diff tool - just for example.

Test:
 - goto to workspace with 2 modified files
1. execute mtn diff --external
   (kdiff3 is spawned)
2.   CTRL+C on terminal
   (kdiff3 lives and ... monotone still lives and ...)
   (at this time crash dump is printed to debug log)
   (second kdiff3 is spawned for next file)
3. Next CTRL+C on terminal
  (no next kdiffs are spawned)
4. Close any of kdiff
  (next kdiff is spawned)
5 Close all kdiffs
  (monotone finally crashes -  reports fatal: memory access violation...
and process ends)
[debug log for session attached]

Well this is strange ... and confirms how badly process control
is messed up on w32.

Daniel, you must have custom external_diff hook, could you send it
together with output of failed monotone execution with --debug flag ?

What shell do  you use ?
Do you confirm this kind of strange monotone behaviour or you have
clean crash CTRL+C === monotone crash ?

Best regards,
-- 
Zbigniew Zagórski
/ software developer / geek / happy daddy /
Debug log of execution mtn diff --external --debug

... cut, unrelevant, lost log
mtn: selected node 2204 guarded_map.h parent 1685
mtn: adding node 2204 guarded_map.h parent 1685
mtn: selected node 2205 guarded_test.cpp parent 1685
mtn: adding node 2205 guarded_test.cpp parent 1685
#
# old_revision [fdce1ddd89744e27d98d6f76ed6bd24261f79fea]
#
# patch guarded_test.cpp
#  from [6190488ef71339e1465a4293b0d5cae2d16f01c0]
#to [adc83b19e793491b1c6ea0fd8b46cd9f32e592fc]
#
# patch http_server.cpp
#  from [09001b30346fccab467ba306972e7ee974d6c4a6]
#to [adc83b19e793491b1c6ea0fd8b46cd9f32e592fc]
#
# patch list_files_generator.cpp
#  from [3fcaa778d753a132cdcb9294d7c2e1b9115eff17]
#to [adc83b19e793491b1c6ea0fd8b46cd9f32e592fc]
#
# patch posix_signals.cpp
#  from [93b66589ab1d8c8ec6f089509503ea9cbf9abe29]
mtn: prepared statement SELECT 1 FROM files WHERE id = ? LIMIT 1
mtn: binding 1 parameters for SELECT 1 FROM files WHERE id = ? LIMIT 1
mtn: binding 1 with value '6190488ef71339e1465a4293b0d5cae2d16f01c0'
mtn: prepared statement SELECT data FROM files WHERE id = ?
mtn: binding 1 parameters for SELECT data FROM files WHERE id = ?
mtn: binding 1 with value '6190488ef71339e1465a4293b0d5cae2d16f01c0'
mtn: loading lua hook external_diff
mtn: searching for exe: kdiff3
mtn: spawning command: 'c:\programs\kdiff3\kdiff3.exe' 'kdiff3 -u -L1 
guarded_test.cpp old C:\DOCUME~1\zagorski\LOCALS~1\Temp/mtn.V3QLTQ -L2 
guarded_test.cpp new C:\DOCUME~1\zagorski\LOCALS~1\Temp/mtn.PEROA6 '

#to [adc83b19e793491b1c6ea0fd8b46cd9f32e592fc]
#
# patch tickedit/tickedit.cpp
#  from [f1d085e6d55543ce948ecfda1db7dda32ff6d0b9]
#to [b525ce7ae4ee15e38cfd624d91323790e9bc9814]
#
COMMENT:  CTRL+C here 
mtn: botan_pipe_cache.hh:41: invariant 'I(!pipe)' violated
mtn: saving current work set: 4 items
mtn: finished saving work set
mtn: contents of work set:
mtn: Current work set: 4 items
mtn: - begin 'system_flavour' (in virtual void sanity::initialize(int, 
char**, const char*), at sanity.cc:75)
mtn: Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 
15, rev 1025)
mtn: -   end 'system_flavour' (in virtual void sanity::initialize(int, 
char**, const char*), at sanity.cc:75)
mtn: - begin 'cmdline_string' (in virtual void sanity::initialize(int, 
char**, const char*), at sanity.cc:89)
mtn: 'mtn', 'diff', '--external', '--debug'
mtn: -   end 'cmdline_string' (in virtual void sanity::initialize(int, 
char**, const char*), at sanity.cc:89)
mtn: - begin 'string(lc_all)' (in virtual void sanity::initialize(int, 
char**, const char*), at sanity.cc:94)
mtn: Polish_Poland.1250
mtn: -   end 'string(lc_all)' (in virtual void sanity::initialize(int, 
char**, const char*), at sanity.cc:94)
mtn: - begin 'full_version_string' (in virtual void 
mtn_sanity::initialize(int, char**, const char*), at mtn-sanity.cc:23)
mtn: monotone 0.42 (base revision: 75ac12dd5b02025981edd6cd03caebb54721e481)
mtn: Running on  : Windows NT/2000/XP/2003 (5.1, build 2600, Service 
Pack 2) on ia32 (level 15, rev 1025)
mtn: C++ compiler: GNU C++ version 3.4.5 (mingw special)
mtn: C++ standard 

automate lua test failure Was: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Thomas Keller
Zbigniew Zagórski schrieb:
 Yep, i've ran test suite before publishing binaries. There were no ...
 err,  almost no failures.
 At least no significant ones.
 
 Failures:
util_mtnopt   because windows doesn't have /bin/sh usually installed
automate_lua  because 3.4 on polish locale is 3,4 grrr

The last failure is intersting. I had exactly the same problem during
the development (because also in the German locale lua converts the dot
to the [correct] comma), but I could fix it by using another way to
convert numbers to strings.

Could you please verify that you get under your locale the same output?

$ lua
Lua 5.1.2  Copyright (C) 1994-2007 Lua.org, PUC-Rio
 print(tostring(3.1))
3.1

Thanks,
Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en




signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: automate lua test failure Was: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Thomas Keller
Thomas Keller schrieb:
 Zbigniew Zagórski schrieb:
 Yep, i've ran test suite before publishing binaries. There were no ...
 err,  almost no failures.
 At least no significant ones.

 Failures:
util_mtnopt   because windows doesn't have /bin/sh usually installed
automate_lua  because 3.4 on polish locale is 3,4 grrr
 
 The last failure is intersting. I had exactly the same problem during
 the development (because also in the German locale lua converts the dot
 to the [correct] comma), but I could fix it by using another way to
 convert numbers to strings.
 
 Could you please verify that you get under your locale the same output?
 
 $ lua
 Lua 5.1.2  Copyright (C) 1994-2007 Lua.org, PUC-Rio
 print(tostring(3.1))
 3.1

I found this [0] explaining that tostring() uses sprintf() which might
be locale-aware or not. The workarounds aren't pretty...

Thomas.

[0] http://lua-users.org/lists/lua-l/2002-04/msg00079.html

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en




signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Marcin W. Dąbrowski
Hi all.

 Can you reproduce what the OP reported?
 Unfortunately no (and yes ... see the end)

+1 from here.

And maybe some additional comment. I'm having this behaviour
on 0.41 as well, and in every situation involving Ctrl-C.

Example:

C:\tmp\mtnmtn log
C:\usr\bin\mtn.exe: fatal: memory access violation
this is almost certainly a bug in monotone.
please send this error message, the output of 'C:\usr\bin\mtn.exe version
--full',
and a description of what you were doing to monotone-devel@nongnu.org


And another:

...
Date: 2009-01-07T13:38:11
Branch: head

Added files:
foo.txtC:\usr\bin\mtn.exe: fatal: undocumented exception
this is almost certainly a bug in monotone.
please send this error message, the output of 'C:\usr\bin\mtn.exe version
--full',
and a description of what you were doing to monotone-devel@nongnu.org

It happens in diff, log, ls... Just in every command with long output.


Running with --debug shows in the middle of the log:

mtn: binding 2 with value 'date'
mtn: cert: signable text
[d...@e3a9275f4d65c2f46b42c0d2999ac73f1aa5f5fa:MjAwOS0wMS0wN1QxMzo0NTo1OA==]
mtn: checking 128-byte signature
mtn: cert ok
mtn: botan_pipe_cache.hh:41: invariant 'I(!pipe)' violated

Does it look like possible bug hive? :)

Rgds.,
-- 
Marcin W. Dabrowski



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Zack Weinberg
On Wed, Jan 7, 2009 at 5:58 AM, Marcin W. Dąbrowski m...@twine.pl wrote:
 Hi all.

 Can you reproduce what the OP reported?
 Unfortunately no (and yes ... see the end)

 +1 from here.

 And maybe some additional comment. I'm having this behaviour
 on 0.41 as well, and in every situation involving Ctrl-C.

At least part of the problem is that we ought to be calling
SetConsoleCtrlHandler in win32/main.cc but we're not.  I'm not sure
why this causes us to wind up in the SEH unhandled exception filter
with a nonsense exception code -- the default Ctrl-C handler
supposedly just kills the process without printing anything.

I don't know why this seems to be interacting with the process
handling code (win32/process.cc) except that I don't like the looks of
the fiddling around with standard handles for I/O redirection that it
does.  We should be using the optional arguments to CreateProcess that
do that instead.  But that might not be what's wrong.

I seem to be the person who ends up writing low-level Windows code
despite that I know about this only what I read in MSDN and don't have
a Windows development environment.  I would really rather not do it
this time -- it looks like something that needs actual testing.

zw
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Daniel Atallah
On Wed, Jan 7, 2009 at 6:04 AM, Zbigniew Zagórski z.zagor...@gmail.com wrote:
 Daniel, you must have custom external_diff hook, could you send it
 together with output of failed monotone execution with --debug flag ?

I do have an custom hook (but it isn't all that weird, as you can see):

function external_diff(file_path, data_old, data_new, is_binary,
diff_args, rev_old, rev_new)
   local old_file = write_to_temporary_file(data_old);

   local path = c:/Program Files/TortoiseSVN/bin/TortoiseMerge.exe
   local ret = execute(path,
  string.format(/base:%s, old_file),
  string.format(/basename:%s, rev_old),
  string.format(/mine:%s, file_path))

   os.remove (old_file);
end

The debug output from the following command:
  C:\devel\pidgin-devel\pidginc:\Program Files\monotone\mtn.exe
diff po/Makefile.mingw --external --debug 2
mtn_diff_external_debug.txt
is available here:
http://pidgin.im/~datallah/mtn/mtn_diff_external_debug.txt

It appears to be the same issue as Marcin W. Dąbrowski is experiencing.

 What shell do  you use ?

I originally was using bash in cygwin (with the native mtn.exe), but I
subsequently tested the issue with cmd.exe and it also occurred there
(and that is how I obtained the above referenced debug log).

 Do you confirm this kind of strange monotone behaviour or you have
 clean crash CTRL+C === monotone crash ?

I'm not sure what you mean here.  I do see the same behavior if I try
to Ctrl+C while a commit is waiting on the external editor if that
answers your question.

Thanks,
Daniel
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


Re: [Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-07 Thread Timothy Brownawell
On Wed, 2009-01-07 at 09:57 -0800, Zack Weinberg wrote:
 On Wed, Jan 7, 2009 at 5:58 AM, Marcin W. Dąbrowski m...@twine.pl wrote:
  Hi all.
 
  Can you reproduce what the OP reported?
  Unfortunately no (and yes ... see the end)
 
  +1 from here.
 
  And maybe some additional comment. I'm having this behaviour
  on 0.41 as well, and in every situation involving Ctrl-C.
 
 At least part of the problem is that we ought to be calling
 SetConsoleCtrlHandler in win32/main.cc but we're not.  I'm not sure
 why this causes us to wind up in the SEH unhandled exception filter
 with a nonsense exception code -- the default Ctrl-C handler
 supposedly just kills the process without printing anything.
 
 I don't know why this seems to be interacting with the process
 handling code (win32/process.cc) except that I don't like the looks of
 the fiddling around with standard handles for I/O redirection that it
 does.  We should be using the optional arguments to CreateProcess that
 do that instead.  But that might not be what's wrong.
 
 I seem to be the person who ends up writing low-level Windows code
 despite that I know about this only what I read in MSDN and don't have
 a Windows development environment.  I would really rather not do it
 this time -- it looks like something that needs actual testing.

I tried using SetConsoleCtrlHandler() with an ExitProcess() in the
handler. This actually resulted in still having an access violation,
which was after the call to ExitProcess(). Not sure what this means...





___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


[Monotone-devel] memory access violation in win32 0.42 when canceling blocked `mtn diff --external` using Ctrl+C

2009-01-06 Thread Daniel Atallah
Since upgrading to 0.42, I've noticed that whenever i cancel an
in-process  (waiting on external diff tool) `mtn diff --external`
using Ctrl+C (I frequently do this when I notice something in one of
the files that are changed that needs fixing to avoid having to go
through the whole list), I get the following output:

c:\Program Files\monotone\mtn.exe: fatal: memory access violation
this is almost certainly a bug in monotone.
please send this error message, the output of 'c:\Program Files\monotone\mtn.exe
 version --full',
and a description of what you were doing to monotone-devel@nongnu.org

Here is the version information:

$ mtn version --full
monotone 0.42 (base revision: 75ac12dd5b02025981edd6cd03caebb54721e481)
Running on  : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 3)
on ia32 (level 6, rev 3846)
C++ compiler: GNU C++ version 3.4.5 (mingw special)
C++ standard library: GNU libstdc++ version 20051201
Boost version   : 1_34_1
Changes since base revision:
unknown


Clearly this isn't a major problem, but I figured I should report it.

Thanks,
-Daniel


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel