FiveTech Support Forums

FiveWin / Harbour / xBase community
Board index FiveWin for Harbour/xHarbour Bug Maria_Connect() FWH-24.07 64 bits ???
Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Sun Sep 22, 2024 07:31 PM

This is a very good question! I will investigate, than you for the idea.

Posts: 514
Joined: Sun Oct 16, 2005 03:32 AM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Sun Sep 22, 2024 09:16 PM
I would be extremely thankful if you kindly take a little more trouble by testing this variation.
This would help me to narrow down the problem
Yes, it works fine.

Thank you, Mr. Rao and Mr. Enrico, for your concern in solving this issue. It is very important for those of us who have chosen xHarbour and Maria_Connect for all our developments.

Saludos,



Carlos Gallego



*** FWH-25.12, xHarbour 1.3.1 Build 20241008, Borland C++7.70, PellesC, ADS 11.1***

Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Sun Sep 22, 2024 09:22 PM
I've sent a private email to Ron and he has responded! He's very busy with a big project but he'll try to help us with this problem. :-)
Posts: 10733
Joined: Sun Nov 19, 2006 05:22 AM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Mon Sep 23, 2024 03:36 AM
It is very important for those of us who have chosen xHarbour and Maria_Connect for all our developments.
Only for xHarbour 64 bit users.
All others are working happily.
Regards



G. N. Rao.

Hyderabad, India
Posts: 10733
Joined: Sun Nov 19, 2006 05:22 AM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Mon Sep 23, 2024 05:20 AM

Testing further.

There are other FWH classes having DESTRUCTOR methods. I did not experience any problem with them. Not also with FWMariaConnection class.

The only problem is with FWMariaRowSet class.

My knowledge is limited.

I would seek the guidance of my seniors to go through the destructor method of rowset class and see what modifications can resolve the conflict, also keeping in view that the problem is only with 64 bits xHarbour.

Regards



G. N. Rao.

Hyderabad, India
Posts: 514
Joined: Sun Oct 16, 2005 03:32 AM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Mon Sep 23, 2024 07:02 PM
Does it mean that it's the end of the road for xHarbour, which is now a stagnant river? :cry:

Saludos,



Carlos Gallego



*** FWH-25.12, xHarbour 1.3.1 Build 20241008, Borland C++7.70, PellesC, ADS 11.1***

Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Mon Sep 23, 2024 07:24 PM
Please compare the changelogs of Harbour and xHarbour. At least they are both "stagnant rivers". :-)

Anyway, we are working to fix the problem. At this stage, it is not yet clear where the problem is, if in xHarbour or in FWH.
Posts: 302
Joined: Fri Apr 23, 2010 04:30 AM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Tue Sep 24, 2024 09:53 PM

I have same problem with xharbour and bcc 64 blits, searching internet i found:

The code you provided uses pointer arithmetic, which can behave differently between 32-bit and 64-bit environments. This is especially relevant when you deal with data structures that involve pointers, as the size of pointers differs between 32-bit and 64-bit systems (4 bytes vs. 8 bytes, respectively).

To make your code compatible with both 32-bit and 64-bit environments, you should address the following points:

  1. Pointer Arithmetic Considerations

In 64-bit mode, the size of pointers is 8 bytes, so pointer arithmetic needs to account for this difference. The line:

cpp

Copy code

( s_pCurrBlock + 1 )

adds 1 to a pointer, which in C/C++ means it advances by the size of the object the pointer points to (based on the type of s_pCurrBlock).

  1. Make Sure s_pCurrBlock is Correctly Sized

If s_pCurrBlock is a structure or class, ensure that the addition of 1 is appropriately aligned. Pointer arithmetic in C++ is based on the size of the object, so s_pCurrBlock + 1 will skip the size of the object.

For example:

In 32-bit mode: If sizeof(s_pCurrBlock) is 4 bytes, adding 1 will move the pointer by 4 bytes.

In 64-bit mode: If sizeof(s_pCurrBlock) is 8 bytes, adding 1 will move the pointer by 8 bytes.

  1. Using uintptr_t for Portability

If you are working with pointer arithmetic in a way that needs to be independent of pointer size, you can cast to uintptr_t. This is a type that is guaranteed to be able to hold a pointer regardless of whether the platform is 32-bit or 64-bit.

Nicanor Martinez M.
Auditoria y Sistemas Ltda.
MicroExpress Ltda.
FW + FWH + XHARBOUR + HARBOUR + PELLES C + XDEVSTUDIO + XEDIT + BCC + VC_X86 + VCC_X64 + MINGW + R&R Reports + FastReport + Tdolphin + ADO + MYSQL + MARIADB + ORACLE
nnicanor@yahoo.com
Posts: 302
Joined: Fri Apr 23, 2010 04:30 AM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Wed Sep 25, 2024 01:11 AM
Hi,

Error is not related with FWMARIA it is related with xharbour, my program uses TDolphin and closes unexpectly not only reading mysql data with those errors in evenlogs,

Abortada conexi脙鲁n 66 para db: 'wadmonbq' usuario: 'wadmon_admin' servidor: 'localhost' (Obtenido un error leyendo paquetes de comunicaci脙鲁n)

For more information, see Help and Support Center at http://www.mysql.com.

Nombre de la aplicaci贸n con errores: SQLWAdmonXBC64.EXE, versi贸n: 3.0.0.1, marca de tiempo: 0x00000000
Nombre del m贸dulo con errores: SQLWAdmonXBC64.EXE, versi贸n: 3.0.0.1, marca de tiempo: 0x00000000
C贸digo de excepci贸n: 0xc0000005
Desplazamiento de errores: 0x00000000000e2074
Identificador del proceso con errores: 0xb32c
Hora de inicio de la aplicaci贸n con errores: 0x01db0e2fd5323833
Ruta de acceso de la aplicaci贸n con errores: H:\ProyectosFW\SQLWadmon\bin64\SQLWAdmonXBC64.EXE
Ruta de acceso del m贸dulo con errores: H:\ProyectosFW\SQLWadmon\bin64\SQLWAdmonXBC64.EXE
Identificador del informe: 4a7c231f-8ea1-4368-82d3-6b47a408f9e6
Nombre completo del paquete con errores:
Identificador de aplicaci贸n relativa del paquete con errores:
Nicanor Martinez M.
Auditoria y Sistemas Ltda.
MicroExpress Ltda.
FW + FWH + XHARBOUR + HARBOUR + PELLES C + XDEVSTUDIO + XEDIT + BCC + VC_X86 + VCC_X64 + MINGW + R&R Reports + FastReport + Tdolphin + ADO + MYSQL + MARIADB + ORACLE
nnicanor@yahoo.com
Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Wed Sep 25, 2024 09:20 AM
Thank you for the info. I dug down the crash here:
Code (fw): Select all Collapse
hb_vmPushSymbol( pDestructor );
hb_vmPush( pObject ); /* Do NOT Forward!!! */
hb_vmSend( 0 ); <-- CRASH HERE!
It is inside the function hb_clsFinalize() that is in classes.c:

https://github.com/xHarbour-org/xharbour/blob/519d78fbf33a2ddb3b3109de2c3f7a888be5c705/source/vm/classes.c#L4076

Can you help me to find the problem, please?
Posts: 302
Joined: Fri Apr 23, 2010 04:30 AM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Wed Sep 25, 2024 02:20 PM
Hi,

This can help

To resolve the issue you're encountering when running the code in Borland C 64-bit, which fails at the `hb_vmSend( 0 );` call, the problem likely arises from differences in memory handling and data types between 32-bit and 64-bit environments. Here are several approaches to debug and potentially avoid the crash:

### 1. **Check Data Types**
The first step is to ensure that the data types you're using are compatible between 32-bit and 64-bit environments. For example, `USHORT`, `BOOL`, and other types may have different sizes in a 64-bit system. Consider replacing `USHORT` with `UINT16` or using fixed-size types from `<stdint.h>` (like `uint16_t`), which will work correctly on both architectures.

### 2. **Review Pointer Usage**
In 64-bit environments, pointers are larger (64-bit compared to 32-bit in 32-bit environments). Review how pointers such as `PHB_ITEM` and `PHB_SYMB` are handled, ensuring there are no pointer truncation issues. Make sure you're not inadvertently casting between 32-bit and 64-bit values, which could lead to problems.

### 3. **Check Stack State**
The `hb_vmSend()` function relies on the state of the Harbour VM stack. Ensure that the stack is in a valid state before invoking `hb_vmSend(0)`. Use debugging tools to verify that the objects being pushed onto the stack (like `pDestructor` and `pObject`) are correct and in the right order. Specifically:
- Ensure that `pDestructor` is valid and not `NULL` before calling `hb_vmSend(0)`.
- Check that `pObject` is a valid reference to a Harbour object.

### 4. **Destructor Control**
In the part of your code controlling whether destructors are enabled:
Code (fw): Select all Collapse
if( s_AllowDestructors /* && hb_stack_ready */ )
You might want to add more thorough checks, such as verifying that the stack is indeed ready using `hb_stack_ready`.

### 5. **Error Handling Around `hb_vmSend()`**
To capture more details about the failure, you can add more explicit error checking before calling `hb_vmSend()`. For example:
Code (fw): Select all Collapse
if (pDestructor && pObject)
{
聽 聽 hb_vmPushSymbol(pDestructor);
聽 聽 hb_vmPush(pObject); /* Do NOT Forward!!! */
聽 聽 if (!hb_vmSend(0)) 
聽 聽 {
聽 聽 聽 聽 // Error handling here, log more details if needed
聽 聽 聽 聽 hb_errInternal(HB_EI_ERRUNRECOV, "Error in hb_vmSend on Borland C 64", NULL, NULL);
聽 聽 }
}
else
{
聽 聽 // Log errors if pDestructor or pObject are invalid
聽 聽 hb_errInternal(HB_EI_ERRUNRECOV, "pDestructor or pObject invalid in Borland C 64", NULL, NULL);
}
### 6. **Verify `hb_vmSend()` Compatibility**
Make sure that the `hb_vmSend()` function implementation is 64-bit compatible and that it鈥檚 not performing operations that are specific to 32-bit environments (like assuming fixed data sizes).

### 7. **Compile with Correct Flags**
Ensure that you're compiling the code with the correct flags for 64-bit. In Borland C, make sure you're using the proper flags to compile for 64-bit, like `-m64` (if applicable), and avoid flags that might force 32-bit compilation.

### 8. **Debug with 64-bit Tools**
Use a 64-bit debugger to analyze memory and stack state right before the `hb_vmSend(0)` call. This can help identify whether the crash is due to a stack overflow, invalid memory access, or another issue specific to 64-bit execution.

By following these steps, you should be able to narrow down the cause of the crash and adjust your code accordingly to work properly in the 64-bit Borland C environment.
Nicanor Martinez M.
Auditoria y Sistemas Ltda.
MicroExpress Ltda.
FW + FWH + XHARBOUR + HARBOUR + PELLES C + XDEVSTUDIO + XEDIT + BCC + VC_X86 + VCC_X64 + MINGW + R&R Reports + FastReport + Tdolphin + ADO + MYSQL + MARIADB + ORACLE
nnicanor@yahoo.com
Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Wed Sep 25, 2024 02:36 PM

I don't need AI response, I need a real help.

Posts: 302
Joined: Fri Apr 23, 2010 04:30 AM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Wed Sep 25, 2024 02:37 PM
More information it maybe help

To optimize the function and avoid unexpected crashes in Borland C 64-bit, you can take a methodical approach focusing on improving type safety, error handling, and ensuring compatibility with the 64-bit architecture. Here are specific optimizations you can apply:

### 1. **Improve Type Safety**
Make sure that all data types are correctly sized for a 64-bit environment. This is especially important for types like `USHORT`, `BOOL`, and pointers. Use fixed-size types from `<stdint.h>` to guarantee consistency across different platforms. For example:

- Replace `USHORT` with `uint16_t`.
- Ensure that pointer types (like `PHB_ITEM` and `PHB_SYMB`) are correctly defined for 64-bit.
Code (fw): Select all Collapse
#include <stdint.h> 聽// for uint16_t

void hb_clsFinalize( PHB_ITEM pObject )
{
聽 聽 HB_THREAD_STUB
聽 聽 uint16_t uiClass; 聽// Changed from USHORT to uint16_t
聽 聽 if( HB_IS_OBJECT( pObject ) )
聽 聽 聽 聽 uiClass = pObject->item.asArray.value->uiClass;
聽 聽 else
聽 聽 聽 聽 return;
### 2. **Validate Pointers Before Access**
In 64-bit, pointer mismanagement is a common source of crashes. Before accessing or using any pointers, ensure they are valid by checking for `NULL` or other invalid states. For example:
Code (fw): Select all Collapse
if (pObject == NULL || pObject->item.asArray.value == NULL)
{
聽 聽 // Log or handle the error
聽 聽 return;
}
This ensures you avoid dereferencing invalid pointers.

### 3. **Use Robust Error Handling**
Ensure robust error handling around critical operations, particularly where you're interacting with the Harbour VM and using stack-based operations (`hb_vmSend`). Add more comprehensive error checks before calling these functions:
Code (fw): Select all Collapse
if (pClass->pDestructor && pObject)
{
聽 聽 hb_vmPushSymbol(pClass->pDestructor->pMessage->pSymbol);
聽 聽 hb_vmPush(pObject);

聽 聽 // Add error handling for hb_vmSend
聽 聽 if (!hb_vmSend(0)) 聽// Handle the case where hb_vmSend fails
聽 聽 {
聽 聽 聽 聽 hb_errInternal(HB_EI_ERRUNRECOV, "hb_vmSend failed", NULL, NULL);
聽 聽 聽 聽 return;
聽 聽 }
}
else
{
聽 聽 hb_errInternal(HB_EI_ERRUNRECOV, "Invalid destructor or object", NULL, NULL);
}
This ensures that if something fails during `hb_vmSend(0)`, the failure is handled gracefully rather than causing a crash.

### 4. **Minimize Stack Usage**
The Harbour VM stack could be another point of failure, especially if it becomes corrupted or misaligned. Minimize direct stack manipulations unless necessary. Check the stack state before and after every operation involving the stack (`hb_stackPush()`, `hb_stackPopState()`).

Ensure the stack is not too deeply nested, as excessive nesting can cause a stack overflow in 64-bit:

[/code]
if (hb_stackBaseItem() == NULL || hb_stackSelfItem() == NULL)
{
// Handle stack corruption or invalid stack state
hb_errInternal(HB_EI_ERRUNRECOV, "Invalid stack state", NULL, NULL);
return;
}
[/code]

### 5. **Disable/Enable Garbage Collection Wisely**
The function disables garbage collection (`hb_gcSetCollecting(TRUE)`) during the destructor call. Be very cautious when disabling and re-enabling garbage collection, and ensure it is balanced and applied correctly. If the destructor fails unexpectedly, you want to make sure the garbage collection state is restored properly:
Code (fw): Select all Collapse
BOOL bCollecting = hb_gcSetCollecting(TRUE);
PHB_SYMB pDestructor = pClass->pDestructor->pMessage->pSymbol;

// Handle errors during destructor execution
if (pDestructor)
{
聽 聽 hb_vmPushSymbol(pDestructor);
聽 聽 hb_vmPush(pObject);
聽 聽 hb_vmSend(0);
}
hb_gcSetCollecting(bCollecting); 聽// Ensure GC is reset even after errors
### 6. **Isolate Problematic Sections**
If you know where the crash is likely happening (for example, around `hb_vmSend(0)`), isolate that code into a separate function and handle exceptions locally, so they don't propagate and crash the entire program. You can use structured exception handling (`try/catch`) or equivalent mechanisms in your environment to catch and handle failures gracefully.

### 7. **Check Compatibility with 64-bit Stack Size**
Borland C 64-bit environments handle the stack differently from 32-bit. Make sure you aren't inadvertently exceeding the stack size or encountering memory alignment issues. If necessary, allocate large objects on the heap instead of the stack.
Code (fw): Select all Collapse
PHB_ITEM* pObjectCopy = (PHB_ITEM*)malloc(sizeof(PHB_ITEM));
if (pObjectCopy == NULL) 
{
聽 聽 // Handle memory allocation failure
聽 聽 return;
}
memcpy(pObjectCopy, pObject, sizeof(PHB_ITEM));
This ensures that larger objects are safely allocated in heap memory, which can handle bigger allocations in 64-bit environments.

### 8. **Compile with Appropriate Flags**
Ensure that your project is being compiled with the correct flags for 64-bit support. These flags ensure correct memory alignment, stack size, and handling of pointers. In Borland C, use the following:

- `-m64`: For 64-bit compilation.
- Ensure optimization flags are enabled for error checking (e.g., `-O2` for optimization, `-g` for debugging).
- If available, enable additional warning levels to catch potential issues at compile time (`-Wall` or equivalent).

### 9. **Use 64-bit Debugging Tools**
Utilize 64-bit debugging tools to check memory, stack, and pointers during runtime. Tools such as Valgrind (for memory checks), gdb (for stack traces), or specialized 64-bit debuggers in Borland C++ can help identify the exact source of the crash.

### Final Optimized Example:
Code (fw): Select all Collapse
void hb_clsFinalize( PHB_ITEM pObject )
{
聽 聽 HB_THREAD_STUB
聽 聽 uint16_t uiClass;

聽 聽 if (!pObject || !HB_IS_OBJECT(pObject) || !pObject->item.asArray.value) {
聽 聽 聽 聽 // Handle invalid object
聽 聽 聽 聽 return;
聽 聽 }

聽 聽 uiClass = pObject->item.asArray.value->uiClass;
聽 聽 if (uiClass && uiClass <= s_uiClasses)
聽 聽 {
聽 聽 聽 聽 PCLASS pClass = s_pClasses + (uiClass - 1);
聽 聽 聽 聽 if (pClass->pDestructor)
聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 if (pClass->uiScope & HB_OO_CLS_DESTRUC_SYMB)
聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 assert(hb_stack_ready);
聽 聽 聽 聽 聽 聽 聽 聽 if (s_AllowDestructors)
聽 聽 聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 if (hb_stackBaseItem() && hb_stackSelfItem() && strcmp(hb_stackBaseItem()->item.asSymbol.value->szName, "__CLSINSTSUPER"))
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 BOOL bCollecting = hb_gcSetCollecting(TRUE);
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 PHB_SYMB pDestructor = pClass->pDestructor->pMessage->pSymbol;

聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 if (pDestructor && pObject)
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_vmPushSymbol(pDestructor);
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_vmPush(pObject);

聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 // Call destructor and handle errors
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 if (!hb_vmSend(0))
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_errInternal(HB_EI_ERRUNRECOV, "Error in hb_vmSend", NULL, NULL);
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 }

聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_gcSetCollecting(bCollecting);
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 聽 聽 聽 聽 else
聽 聽 聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_errInternal(HB_EI_ERRUNRECOV, "Destructors disabled!", pClass->szName, NULL);
聽 聽 聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 }
聽 聽 }
}

By following these steps, you can improve the robustness of your function and reduce the likelihood of unexpected crashes in Borland C 64-bit.

Alterantive function by claude maybe help:
Code (fw): Select all Collapse
B_BOOL hb_vm_ready( void )
{
聽 聽/* Verificar si la pila de la m谩quina virtual est谩 inicializada */
聽 聽if( !hb_stack_ready )
聽 聽{
聽 聽 聽 return HB_FALSE;
聽 聽}

聽 聽/* Verificar si el puntero de la m谩quina virtual es v谩lido */
聽 聽if( hb_vm_ptr() == NULL )
聽 聽{
聽 聽 聽 return HB_FALSE;
聽 聽}

聽 聽/* Verificar si el 谩rea de memoria de la m谩quina virtual est谩 inicializada */
聽 聽if( hb_vmMemoryPtr() == NULL )
聽 聽{
聽 聽 聽 return HB_FALSE;
聽 聽}

聽 聽/* Puedes agregar m谩s verificaciones aqu铆 si es necesario */

聽 聽return HB_TRUE;
}



void hb_clsFinalize( PHB_ITEM pObject )
{
聽 聽HB_THREAD_STUB
聽 聽USHORT uiClass;
聽 聽if( HB_IS_OBJECT( pObject ) )
聽 聽 聽 uiClass = pObject->item.asArray.value->uiClass;
聽 聽else
聽 聽 聽 return;

聽 聽if( uiClass && uiClass <= s_uiClasses )
聽 聽{
聽 聽 聽 PCLASS pClass = s_pClasses + ( uiClass - 1 );
聽 聽 聽 if( pClass->pDestructor )
聽 聽 聽 {
聽 聽 聽 聽 聽if( pClass->uiScope & HB_OO_CLS_DESTRUC_SYMB )
聽 聽 聽 聽 聽{
聽 聽 聽 聽 聽 聽 assert( hb_stack_ready );
聽 聽 聽 聽 聽 聽 if( s_AllowDestructors )
聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽if( HB_IS_SYMBOL( hb_stackBaseItem() ) &&
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽( hb_stackBaseItem()->item.asSymbol.pCargo->uiSuperClass == 0 || 
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽( USHORT ) hb_stackBaseItem()->item.asSymbol.pCargo->uiSuperClass != uiClass ||
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽( HB_IS_ARRAY( hb_stackSelfItem() ) && 
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽hb_stackSelfItem()->item.asArray.value != pObject->item.asArray.value ) ) && 
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽strcmp( hb_stackBaseItem()->item.asSymbol.value->szName, "__CLSINSTSUPER" ) )
聽 聽 聽 聽 聽 聽 聽 聽{
聽 聽 聽 聽 聽 聽 聽 聽 聽 BOOL 聽 聽 bCollecting = hb_gcSetCollecting( TRUE ), bPop = TRUE;
聽 聽 聽 聽 聽 聽 聽 聽 聽 PHB_SYMB pDestructor = pClass->pDestructor->pMessage->pSymbol;

聽 聽 聽 聽 聽 聽 聽 聽 聽 if( HB_IS_ARRAY( &HB_VM_STACK.Return ) && 
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 HB_VM_STACK.Return.item.asArray.value == pObject->item.asArray.value )
聽 聽 聽 聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽bPop = FALSE;
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽hb_stackPush();
聽 聽 聽 聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 聽 聽 聽 聽 聽 else
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽hb_vmPushState();

聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_vmPushSymbol( pDestructor );
聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_vmPush( pObject );

聽 聽 聽 聽 聽 聽 聽 聽 聽 #ifdef __BORLANDC__
聽 聽 聽 聽 聽 聽 聽 聽 聽 #if __BORLANDC__ > 0x0580 聽// Ajusta este valor seg煤n la versi贸n de Borland C 64-bit
聽 聽 聽 聽 聽 聽 聽 聽 聽 // Alternativa para 64-bit
聽 聽 聽 聽 聽 聽 聽 聽 聽 if (hb_vm_ready()) 聽// Asume que existe una funci贸n como esta
聽 聽 聽 聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽// Llama directamente al destructor si es posible
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽if (pDestructor && pDestructor->value)
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽{
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 pDestructor->value(pObject);
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽}
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽else
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽{
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 // Registra un error o maneja la situaci贸n de otra manera
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_errInternal(HB_EI_ERRUNRECOV, "Unable to call destructor", NULL, NULL);
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽}
聽 聽 聽 聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 聽 聽 聽 聽 聽 else
聽 聽 聽 聽 聽 聽 聽 聽 聽 {
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽hb_errInternal(HB_EI_ERRUNRECOV, "Harbour VM not ready", NULL, NULL);
聽 聽 聽 聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 聽 聽 聽 聽 聽 #else
聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_vmSend( 0 );
聽 聽 聽 聽 聽 聽 聽 聽 聽 #endif
聽 聽 聽 聽 聽 聽 聽 聽 聽 #else
聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_vmSend( 0 );
聽 聽 聽 聽 聽 聽 聽 聽 聽 #endif

聽 聽 聽 聽 聽 聽 聽 聽 聽 if( bPop )
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽hb_vmPopState();
聽 聽 聽 聽 聽 聽 聽 聽 聽 else
聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽hb_stackDec();

聽 聽 聽 聽 聽 聽 聽 聽 聽 hb_gcSetCollecting( bCollecting );
聽 聽 聽 聽 聽 聽 聽 聽}
聽 聽 聽 聽 聽 聽 }
聽 聽 聽 聽 聽 聽 else
聽 聽 聽 聽 聽 聽 聽 聽hb_errInternal( HB_EI_ERRUNRECOV, "Destructors disabled! Destructor of class: '%s' can't be executed.", pClass->szName, NULL );
聽 聽 聽 聽 聽}
聽 聽 聽 }
聽 聽}
}
Nicanor Martinez M.
Auditoria y Sistemas Ltda.
MicroExpress Ltda.
FW + FWH + XHARBOUR + HARBOUR + PELLES C + XDEVSTUDIO + XEDIT + BCC + VC_X86 + VCC_X64 + MINGW + R&R Reports + FastReport + Tdolphin + ADO + MYSQL + MARIADB + ORACLE
nnicanor@yahoo.com
Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Thu Sep 26, 2024 01:50 PM

Keep in mind that all is working fine using MSC64, so the problem can't be something related to 64 bit handling. And moreover, I can't trap the crash because the call to hb_vmSend( 0 ) crashes che program and never returns. And I cannot use try/catch, we are using C not C++ in this module.

Posts: 9020
Joined: Thu Oct 06, 2005 08:17 PM
Re: Bug Maria_Connect() FWH-24.07 64 bits ???
Posted: Thu Sep 26, 2024 02:26 PM
I found this in fwmaria.prg:
Code (fw): Select all Collapse
#ifdef MSVC32

#define NXS_MAX_KEYLEN 聽256

static void nxs_crypt(
聽 聽const unsigned char * source, HB_SIZE srclen,
聽 聽const unsigned char * key, HB_SIZE keylen,
聽 聽unsigned char * cipher );

static void nxs_scramble(
聽 聽const unsigned char * source, HB_SIZE srclen,
聽 聽const unsigned char * key, HB_SIZE keylen,
聽 聽unsigned char * cipher );

static void nxs_partial_scramble(
聽 聽const unsigned char * source, unsigned char * cipher,
聽 聽HB_ISIZ * scramble,
聽 聽HB_SIZE len, HB_SIZE keylen );

static void nxs_xorcode(
聽 聽unsigned char * cipher, HB_SIZE cipherlen,
聽 聽const unsigned char * key, HB_SIZE keylen );

static void nxs_xorcyclic(
聽 聽unsigned char * cipher, HB_SIZE cipherlen,
聽 聽const unsigned char * key, HB_SIZE keylen );

static HB_U32 nxs_cyclic_sequence( HB_U32 input );

static void nxs_make_scramble(
聽 聽HB_ISIZ * scramble,
聽 聽const unsigned char * key,
聽 聽HB_SIZE keylen );

#else

void nxs_crypt(
聽 聽const unsigned char *source, HB_SIZE srclen,
聽 聽const unsigned char *key, HB_SIZE keylen,
聽 聽unsigned char *cipher );

#endif
Consider that MSVC32 is never defined, so why that code? When I try the sample with MSC32 I get:
Code (fw): Select all Collapse
error LNK2019: unresolved external symbol _nxs_crypt referenced in function _HB_FUN_MYSQL_CRYPT