Issue
Appeared during a normal "unlock" command. --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.11\ext\subversion\subversion\libsvn_subr\token.c' line 51: internal malfunction --- OK ---
Re: Issue
That malfunction comes from svn_token__from_word_strict():
int
svn_token__from_word_strict(const svn_token_map_t *map,
const char *word)
{
int value = svn_token__from_word(map, word);
if (value == SVN_TOKEN_UNKNOWN)
SVN_ERR_MALFUNCTION_NO_RETURN();
return value;
}
Not much to go on here, unfortunately. Obviously if the problem was the
result of an *entirely normal* unlock command, our regression test would be
expected to catch it. But I don't see enough in the issue report to help us
understand what was *not* entirely normal about this operation. (For any
devs taking note, "token" in the sense of the function above is not the lock
token, but is instead a serialized string token that the function is trying
to map to an internal integer code (e.g., an enum).)
On 03/14/2013 05:39 AM, rafael.zal...@infineon.com wrote:
>
> Appeared during a normal “unlock” command.
>
>
>
>
>
> ---
>
> Subversion Exception!
>
> ---
>
> Subversion encountered a serious problem.
>
> Please take the time to report this on the Subversion mailing list
>
> with as much information as possible about what
>
> you were trying to do.
>
> But please first search the mailing list archives for the error message
>
> to avoid reporting the same problem repeatedly.
>
> You can find the mailing list archives at
>
> http://subversion.apache.org/mailing-lists.html
>
>
>
> Subversion reported the following
>
> (you can copy the content of this dialog
>
> to the clipboard using Ctrl-C):
>
>
>
> In file
>
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.11\ext\subversion\subversion\libsvn_subr\token.c'
>
> line 51: internal malfunction
>
> ---
>
> OK
>
> ---
>
--
C. Michael Pilato
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
Re: Issue
C. Michael Pilato wrote on Thu, Mar 14, 2013 at 09:53:27 -0400:
> That malfunction comes from svn_token__from_word_strict():
>
> int
> svn_token__from_word_strict(const svn_token_map_t *map,
> const char *word)
> {
> int value = svn_token__from_word(map, word);
>
> if (value == SVN_TOKEN_UNKNOWN)
> SVN_ERR_MALFUNCTION_NO_RETURN();
>
> return value;
> }
>
> Not much to go on here, unfortunately. Obviously if the problem was the
Fortunately there are very few svn_token_map_t instances in the code:
% svn info | grep URL | sed 's#.*/##"
1.7.x
% grep -R svn_token_map_t subversion/libsvn*/*.[hc] | fgrep \[ | grep -vw
extern
subversion/libsvn_subr/date.c:static svn_token_map_t number_words_map[] = {
subversion/libsvn_wc/tree_conflicts.c:static const svn_token_map_t
node_kind_map[] =
subversion/libsvn_wc/tree_conflicts.c:const svn_token_map_t
svn_wc__operation_map[] =
subversion/libsvn_wc/tree_conflicts.c:const svn_token_map_t
svn_wc__conflict_action_map[] =
subversion/libsvn_wc/tree_conflicts.c:const svn_token_map_t
svn_wc__conflict_reason_map[] =
subversion/libsvn_wc/wc_db.c:static const svn_token_map_t kind_map[] = {
subversion/libsvn_wc/wc_db.c:static const svn_token_map_t presence_map[] = {
I think the last one is the most likely victim (particularly since
there's a comment next to it declaring it a "subset" of the possible
values), but locks have dates in their metadata so the first and sixth
results are also candidates.
Rafael: did you have any conflicted files in your working copy?
Daniel
> result of an *entirely normal* unlock command, our regression test would be
> expected to catch it. But I don't see enough in the issue report to help us
> understand what was *not* entirely normal about this operation. (For any
> devs taking note, "token" in the sense of the function above is not the lock
> token, but is instead a serialized string token that the function is trying
> to map to an internal integer code (e.g., an enum).)
>
> On 03/14/2013 05:39 AM, rafael.zal...@infineon.com wrote:
> >
> > Appeared during a normal “unlock” command.
> >
> >
> >
> >
> >
> > ---
> >
> > Subversion Exception!
> >
> > ---
> >
> > Subversion encountered a serious problem.
> >
> > Please take the time to report this on the Subversion mailing list
> >
> > with as much information as possible about what
> >
> > you were trying to do.
> >
> > But please first search the mailing list archives for the error message
> >
> > to avoid reporting the same problem repeatedly.
> >
> > You can find the mailing list archives at
> >
> > http://subversion.apache.org/mailing-lists.html
> >
> >
> >
> > Subversion reported the following
> >
> > (you can copy the content of this dialog
> >
> > to the clipboard using Ctrl-C):
> >
> >
> >
> > In file
> >
> > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.11\ext\subversion\subversion\libsvn_subr\token.c'
> >
> > line 51: internal malfunction
> >
> > ---
> >
> > OK
> >
> > ---
> >
>
>
> --
> C. Michael Pilato
> CollabNet <> www.collab.net <> Enterprise Cloud Development
>
Re: Issue
Daniel Shahaf wrote on Fri, Mar 15, 2013 at 00:57:49 +0200:
> C. Michael Pilato wrote on Thu, Mar 14, 2013 at 09:53:27 -0400:
> > That malfunction comes from svn_token__from_word_strict():
> >
> > int
> > svn_token__from_word_strict(const svn_token_map_t *map,
> > const char *word)
> > {
> > int value = svn_token__from_word(map, word);
> >
> > if (value == SVN_TOKEN_UNKNOWN)
> > SVN_ERR_MALFUNCTION_NO_RETURN();
> >
> > return value;
> > }
> >
> > Not much to go on here, unfortunately. Obviously if the problem was the
>
> Fortunately there are very few svn_token_map_t instances in the code:
P.S. I didn't check whether tsvn's code uses svn_token_map_t directly
(or has a code path that can call into svn_token__from_word_strict()).
Fwd: SvnServe with Windows AD Authendication
-- Forwarded message -- From: Nico Kadel-Garcia Date: Fri, Mar 15, 2013 at 12:01 AM Subject: Re: SvnServe with Windows AD Authendication To: Joseba Ercilla Olabarri On Tue, Mar 12, 2013 at 5:55 PM, Joseba Ercilla Olabarri wrote: > On Tue, Mar 12, 2013 at 2:45 PM, Krishnamoorthi Gopal > wrote: >> >> >> Our management requested to upgrade this version into 7.X with AD >> integration ( Only we need to use SVN ://) >> >> Is possible? ..please advise > > > Actually, what you need is a SSH server for windows that supports: > 1) Tunneling ssh sessions to local (server) svnserve command executions > 2) Authenticating ssh session through LDAP > > Apparently there is a version of openSSH for windows, but don't know it's > current state neither about what features had been ported. > I'm currently using 1) like setup (but not on windows) working fine. > I haven't try 2) Perhaps somebody else can contribute. > > Having said that, you probably have the perfect excuse to a) change the OS > or b) add http support. This doesn't work quite right. Unless there is only a single svn+ssh client, or unless permissions for the repository itself are managed very carefully to provide write access to the database and read/execute to any hook scripts, but not write permission to anything else, it's a security risk because every normal SSH services allow a greate deal of open access to most of the file system. The only Subbersion compatible way to restrict this is to use a shared single user account, with "authorized_keys" set up to force SSH key use with restricted operations with those keys. These permissions are neither published, nor easily replicated, with svnsync or similar SVN mirroring tools, so backup and configuration replication can be an adventure. The svn+ssh key management is a pain in the neck to set up, since I've never seen a published tool to manage these well (comparable to the "gitolite" tool for SSH key management through a source controlled public SSH key repository.) But in my opinion, it should be listed *FIRST* as the most effective svn+ssh access control, instead of last. People tend to work their way down the list and do the simplest tsetup they can get working, and the result is often a poor security model for a critical source control repository.
