Announcement

Collapse
No announcement yet.

Miva Merchant Empresa Bugs?

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RayYates
    replied
    Re: Miva Merchant Empresa Bugs?

    Miva Merchant 5.5
    Production Release 8 Update 6
    Miva Merchant Engine v5.13
    Database API: mysql



    This seems to be a Template Compiler bug, I did not test the with equivalent Mivascript code, but I think I remember Bruce G having the same problem a while back.

    The conditional <mvt:if expr="( g.test[1]:code EQ l.settings:topcat:code )"> causes the null array g.test to stop being null.

    Sampe code
    Code:
    <mvt:item name="ry_toolbelt" param="assign|g.max|miva_array_max(g.test)" />
    ~&mvt:global:max;~<br>
    
    <mvt:if expr="( g.test[1]:code EQ l.settings:topcat:code )">
    
    </mvt:if>
    
    <mvt:item name="ry_toolbelt" param="assign|g.max|miva_array_max(g.test)" />
    ~&mvt:global:max;~<br>
    Result:
    ~0~
    ~1~

    Leave a comment:


  • burch
    replied
    Re: Miva Merchant Empresa Bugs?

    Thank you for the bug report. We were already aware of the issue and it will be fixed in 5.14. I've added your information to our internal defect report.

    Leave a comment:


  • John Stange
    replied
    Re: MIVA Empresa Bugs?

    Found a trivially reproducible segfault in 5.13 in the config file parser library (distributed as 3x.so); tested on CentOS 4 with the i386 binary. Omitting a field in one of the config file entries will get you a crash; expected behavior would be a parse error and orderly exit.

    Example config line to reproduce:

    <DATABASE-LIB LIBRARY ="/home3/johnsons/upgrade/public_html/cgi-bin/lib/databases/mivasql.so">

    (note that the above omits the METHOD field)

    Resulting stack trace (using Valgrind) below, which suggests a simple NULL pointer dereference problem. Probably a quick fix.

    ==1234== Memcheck, a memory error detector.
    ==1234== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
    ==1234== Using LibVEX rev 1575, a library for dynamic binary translation.
    ==1234== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
    ==1234== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
    ==1234== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
    ==1234== For more details, rerun with: -v
    ==1234==
    ==1234== Invalid read of size 1
    ==1234== at 0x4005E7C: strlen (mac_replace_strmem.c:243)
    ==1234== by 0x80983CB: CommerceLibrary::CommerceLibrary(char const *, char const *) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x8098803: CommerceLibraryManager::RegisterDSO(char const *, char const *) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x80A6AA1: ExternalConfig::Register_Library_Commerce(char const *, char const *) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x8114E82: mvConfig_Register_Library_Commerce (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x411B7A0: config3x_tag_end (in /someuser/webroot/cgi-bin/libmivaconfig.so)
    ==1234== by 0x411CEBE: config_parse (in /someuser/webroot/cgi-bin/libmivaconfig.so)
    ==1234== by 0x411A852: config3x_loadconfiguration (in /someuser/webroot/cgi-bin/libmivaconfig.so)
    ==1234== by 0x4119D3A: config3x_api_init (in /someuser/webroot/cgi-bin/libmivaconfig.so)
    ==1234== by 0x80A65AC: ExternalConfig::Load(char const *, int, void *, int) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x8078EE7: CGIApplication::LoadConfiguration(void) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x807870B: CGIApplication::Go(void) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== Address 0x0 is not stack'd, malloc'd or (recently) free'd
    ==1234==
    ==1234== Process terminating with default action of signal 11 (SIGSEGV)
    ==1234== Access not within mapped region at address 0x0
    ==1234== at 0x4005E7C: strlen (mac_replace_strmem.c:243)
    ==1234== by 0x80983CB: CommerceLibrary::CommerceLibrary(char const *, char const *) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x8098803: CommerceLibraryManager::RegisterDSO(char const *, char const *) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x80A6AA1: ExternalConfig::Register_Library_Commerce(char const *, char const *) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x8114E82: mvConfig_Register_Library_Commerce (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x411B7A0: config3x_tag_end (in /someuser/webroot/cgi-bin/libmivaconfig.so)
    ==1234== by 0x411CEBE: config_parse (in /someuser/webroot/cgi-bin/libmivaconfig.so)
    ==1234== by 0x411A852: config3x_loadconfiguration (in /someuser/webroot/cgi-bin/libmivaconfig.so)
    ==1234== by 0x4119D3A: config3x_api_init (in /someuser/webroot/cgi-bin/libmivaconfig.so)
    ==1234== by 0x80A65AC: ExternalConfig::Load(char const *, int, void *, int) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x8078EE7: CGIApplication::LoadConfiguration(void) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234== by 0x807870B: CGIApplication::Go(void) (in /someuser/webroot/cgi-bin/mivavm)
    ==1234==
    ==1234== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 33 from 2)
    ==1234== malloc/free: in use at exit: 284,989 bytes in 164 blocks.
    ==1234== malloc/free: 194 allocs, 30 frees, 285,916 bytes allocated.
    ==1234== For counts of detected errors, rerun with: -v
    ==1234== searching for pointers to 164 not-freed blocks.
    ==1234== checked 808,896 bytes.
    ==1234==
    ==1234== LEAK SUMMARY:
    ==1234== definitely lost: 80 bytes in 16 blocks.
    ==1234== possibly lost: 0 bytes in 0 blocks.
    ==1234== still reachable: 284,909 bytes in 148 blocks.
    ==1234== suppressed: 0 bytes in 0 blocks.
    ==1234== Use --leak-check=full to see details of leaked memory.
    Segmentation fault

    Leave a comment:


  • eageclott
    replied
    Miva Merchant Empresa Bugs

    I dont personally care for them, but have you tried paypal?

    Leave a comment:


  • Emma
    replied
    Re: Miva Merchant Empresa Bugs?

    Originally posted by Claudiu View Post
    I think I found a good one. Here is the post:

    http://extranet.mivamerchant.com/for...d.php?t=106096
    Please ignore. I wasn't aware about the feature... Thank you

    Leave a comment:


  • Emma
    replied
    Re: Miva Merchant Empresa Bugs?

    I think I found a good one. Here is the post:

    http://extranet.mivamerchant.com/for...d.php?t=106096

    Best
    Claudiu

    Leave a comment:


  • Silas Creative
    replied
    Re: Miva Merchant Empresa Bugs?

    Having a strange bug with Empresa 5.08 on Hostasaurus server...

    I get an error with this...
    <MvASSIGN NAME="l.val" VALUE="{fsrename(l.old, l.new)}">
    that 'moves' a file/dir from the data dir, to the web dir. *It seemed to work on files, but not on dirs.

    The other command that failed was 'tar_extract'

    Anyone have any thoughts?

    Leave a comment:


  • Rick Wilson
    replied
    Re: Miva Merchant Empresa Bugs?

    Markus,

    I think I accidentally approved spam, I've deleted it and him.

    Leave a comment:


  • mvmarkus
    replied
    Re: Miva Merchant Empresa Bugs

    Originally posted by raifiesee
    geez it hasnt been implemented on the main servers yet and people are already complaining that its overpowered.... cant ANY class get anything good without ppl QQing bout it?
    Hmmm, what are you talking about?

    Markus

    Leave a comment:


  • netiskiv
    replied
    Re: MIVA Empresa Bugs?

    Originally posted by aGorilla View Post
    Two bugs on Mia, not confirmed on Empressa.

    file_create(l.file, 'data', somedb.d.field) Kills Mia
    Assigning the db field to a local variable, and then using the local variable in the file_create solves the problem.

    using bf_encrypt on an empty string kills Mia.
    file_read(l.file, 'script", somedb.d.field) Kills Mia (5.06) as well.

    Irene

    Leave a comment:


  • Mark Johnson
    replied
    Re: [IMPORTANT] Critical Arithmetic Bug in 5.06

    Originally posted by truXoft View Post
    Empresa and Mia v5.06 parse simple arithmetic functions wrong and inconsistently which may lead to completely false results in simple calculations. This happens when an expression is passed through MvDO, and possibly in other MIVA Script tags too. Below there is a sample code demonstrating the fatal bug. Compile it and run to see the illogical results for the simple expression A - B - C. In old versions such expressions worked well; currently it is necessary to transcribe them into logically identical equivalent of A - (B + C) :
    HTML Code:
    <h3>Plain expression</h3>
    <MvASSIGN NAME="l.res1" VALUE="{5 - 1 - 3}">
    <MvASSIGN NAME="l.res2" VALUE="{5 - (1 + 3)}">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <h3>Expression in a function argument in MvDO</h3>
    <MvDO FILE="test.mvc" NAME="l.res1" VALUE="{test(5 - 1 - 3)}">
    <MvDO FILE="test.mvc" NAME="l.res2" VALUE="{test(5 - (1 + 3))}">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <h3>Expression directly in MvDO</h3>
    <MvDO FILE="test.mvc" NAME="l.res1" VALUE="{5 - 1 - 3}">
    <MvDO FILE="test.mvc" NAME="l.res2" VALUE="{5 - (1 + 3)}">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <MvFUNCTION NAME="test" PARAMETERS="val">
     <MVFUNCRETURN VALUE="{l.val}">
    </MVFUNCTION>
     
    <MvFUNCTION NAME="result" PARAMETERS="val1 VAR, val2 VAR">
     <MvIF EXPR="{l.val1 NE l.val2}">
       <MVFUNCRETURN VALUE="{'<span style="color:red">' $ l.val1 $ ' != ' $ l.val2 $ '</span>'}">
     <MvELSE>
       <MVFUNCRETURN VALUE="{l.val1 $ ' == ' $ l.val2}">
     </MvIF>
    </MVFUNCTION>
    The test program should show three times 1 == 1 but instead it shows the incorrect result 7 != 1 for the last two calculations passing the expression through MvDO. MvASSIGN and MvEVAL work correctly, but I suspect the same problem may pop up in other commands too (such as MvFILTER, index expressions, etc).
    It turns out that MvDO uses a completely separate parser to compile its VALUE expression at run time. This parser is also used in the filter expressions of MvIMPORT and in the template compiler. This parser was evaluating all operators of equal precedence right to left. Of course the parser in the compiler evaluates left to right. In the long run I would like to use a single parser to guarantee consistent behavior. In the meantime I just fixed the runtime expression parser. This fix is in engine version 5.07a4 and later.

    Here is the revised test program that I used to work on this issue. Thanks again Ivo for documenting this so well.

    HTML Code:
    <HTML>
    <HEAD><TITLE>Miva Test Application</TITLE></HEAD>
    
    <BODY BGCOLOR = "#ffffff">
    <B>Miva Test Application</B><BR>
    Running under Miva v<B><MvEVAL EXPR = "{ s.mivaversion }"></B><br><br>
    
    <h3>Plain expression</h3>
    <MvASSIGN NAME="l.res1" VALUE="{5 - 1 - 3}">
    <MvASSIGN NAME="l.res2" VALUE="{( 5 - 1 ) - 3}">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <h3>Expression in a function argument</h3>
    <MvASSIGN NAME="l.res1" VALUE="{test(5 - 1 - 3)}">
    <MvASSIGN NAME="l.res2" VALUE="{test(( 5 - 1 ) - 3)}">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <h3>Expression directly in MvDO</h3>
    <MvDO FILE="test.mvc" NAME="l.res1" VALUE="{5 - 1 - 3}">
    <MvDO FILE="test.mvc" NAME="l.res2" VALUE="{( 5 - 1 ) - 3}">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <h3>Expression in a function argument in MvDO</h3>
    <MvDO FILE="test.mvc" NAME="l.res1" VALUE="{test(5 - 1 - 3)}">
    <MvDO FILE="test.mvc" NAME="l.res2" VALUE="{test(( 5 - 1 ) - 3)}">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <h3>Expression directly in implied MvDO</h3>
    <MvASSIGN NAME="l.dofile" VALUE="test.mvc">
    <MvASSIGN NAME="l.res1" VALUE="{ [ l.dofile ].( 5 - 1 - 3 ) }">
    <MvASSIGN NAME="l.res2" VALUE="{ [ l.dofile ].( ( 5 - 1 ) - 3 ) }">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <h3>Expression in a function argument in implied MvDO</h3>
    <MvASSIGN NAME="l.res1" VALUE="{ [ l.dofile ].test(5 - 1 - 3)}">
    <MvASSIGN NAME="l.res2" VALUE="{ [ l.dofile ].test(( 5 - 1 ) - 3)}">
    <MvEVAL EXPR="{result(l.res1,l.res2)}">
     
    <MvFUNCTION NAME="test" PARAMETERS="val">
     <MVFUNCRETURN VALUE="{l.val}">
    </MVFUNCTION>
     
    <MvFUNCTION NAME="result" PARAMETERS="val1 VAR, val2 VAR">
     <MvIF EXPR="{l.val1 NE l.val2}">
       <MVFUNCRETURN VALUE="{'<span style="color:red">' $ l.val1 $ ' != ' $ l.val2 $ '</span>'}">
     <MvELSE>
       <MVFUNCRETURN VALUE="{l.val1 $ ' == ' $ l.val2}">
     </MvIF>
    </MVFUNCTION>

    Leave a comment:


  • Rick Wilson
    replied
    Re: Miva Merchant Empresa Bugs?

    And, if so, does that apply also apply to websites on a shared server for which the MvCONFIG_COOKIES_SECURE is 'No'
    No, in this case shared certs would work just fine.

    Leave a comment:


  • Jeff - Wolfpaw Hosting
    replied
    Re: Miva Merchant Empresa Bugs?

    Rick - just got a copy of 5.07a1 with the McAfee unsecure cookie fix. I remember reading that using this fix meant that the site could not use a shared SSL cert. Is that still true? And, if so, does that apply also apply to websites on a shared server for which the MvCONFIG_COOKIES_SECURE is 'No' ?

    Thanks

    Leave a comment:


  • emione
    replied
    Re: Miva Merchant Empresa Bugs?

    Originally posted by Rick Wilson View Post
    Personally, I wouldn't wait. It's not in beta because it's unstable, it's in beta because I don't want to divert our focus from Miva Merchant development just to formally release it. We might end up leaving it in beta for a very long time.
    Thanks.

    Leave a comment:


  • Rick Wilson
    replied
    Re: Miva Merchant Empresa Bugs?

    Personally, I wouldn't wait. It's not in beta because it's unstable, it's in beta because I don't want to divert our focus from Miva Merchant development just to formally release it. We might end up leaving it in beta for a very long time.

    Leave a comment:

Working...
X